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ABSTRACT 


This  thssls  describes  the  functions  of  the  Database 
Administrator  (DBA)  and  ho*  they  are  supported  by  the 
benchmarked  relational  database  machine.  An  examination  of 
the  relational  query  language  provided,  DBA  support  services 
•  required,  the  performance  issues  involved,  and  tne  security 
features  employed  is  presented.  The  goal  of  this  work  is  to 
develop  general  guidelines  for  DBA  to  follow  in  implementing 
and  operating  an  effective,  responsive  database  system. 
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I.  AN  INTRODUCTION 


Although  tht  application  of  software  database  management 
systems  to  user  requirements  is  not  new  there  are  emerging 
special-purpose  hardware  systems  which  will  relieve  tne  nest 
central  processing  unit  (CPU)  from  the  time  consuming 
processes  of  accessing,  updating,  and  modifying  data. 
Numerous,  commerclally-available  software  database 
management  systems  for  the  host  computers  are  currently 
employed  In  application  areas  but  there  appears  to  be 
associated  performance  degradation  In  the  host  machines. 
These  performance  issues  must  be  Identified  and  performance 
measured  In  order  to  provided  seme  quantitative  comparisons 
betvean  software  systems,  general-purpose  hardware  systems, 
and  special-purpose  hardware  systems.  Historically  this 
Information  has  bean  collected  for  general-purpose  computers 
by  the  use  of  the  Instruction  mix  (Gibson  or  Flynn)  to 
measure  performance  In  various  categories.  This  measurement 
of  a  machine  using  an  Instruction  as  a  tool  mix  is  called 
benchmarking. 

The  task  of  benchmarking  a  database  system  has  not  been 
developed  In  the  literature.  Consequently,  a  research 
project  has  been  undertaken  by  the  Naval  Postgraduate  senool 
to  develop  a  set  of  benchmarking  standards  which  can  be 
employed  to  obtain  a  performance  index  of  a  particular 


database  machine/system  and  further  used  in  a  comparative 
analysis  with  respect  to  other  datacase  systems/machines. 

The  Initial  steps  in  the  benchmark  development  have  been 
limited  to  a  specific  relational  database  machine.  In 
addition  to  the  measurements  of  specific  database 
operations,  a  question  of  the  role  and  responsibilities  of 
the  database  administrator  (DBA)  is  posed,  **ith  each  system 
benchmarked,  there  is  a  need  to  establish  the  amount  of 
support  provided  to  DBA,  In  this  ease  an  examination  of  the 
facilities  provided,  query  lanquage  employed,  and  amount  of 
additional  DBA  support  required  is  conducted. 

The  objective  of  this  thesis  is  to  categorize  the  duties 
and  responsibilities  of  DBA  and  descrioe  how  they  are 
supported  by  the  benchmarked  system.  At  the  beginning,  the 
system  environment  is  described,  followed  by  a  discussion  of 
the  query  language.  An  analysis  of  Dba  functions  is  then 
made  and  finally,  the  fully  relational  model  is  examined  and 
a  comparison  of  this  particular  query  language  with  another 
well-known  language  is  made. 

This  thesis  is  one  in  a  series  of  four  describing  the 
current  status  of  the  benchmark  development.  The  other 
three  topics  are  on  generating  the  synthetic  database  [Ref, 
11,  selection  and  projection  [Ref,  21,  and  join  operations 
CRef.  3). 
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II.  THE  BENCHMARKING  ENVIRONMENT 


A.  THE  HOST  SYSTEM 

The  host  machine  for  the  benchmark  is  Unlvac  1100/42 
located  at  Pacific  Missile  lest  Center,  Point  Mugu, 
California.  In  addition  to  or-site  eoulpment,  a  remote 
terminal  is  Installed  at  the  Naval  Postgraduate  School. 

1.  The  Hardware  Interface 

The  hardware  interface  between  the  host  and  the 
database  machine  is  through  a  Unlvae  1100/42  I/O  channel. 
This  interface  channel  has  a  200-thousand  byte/seecnd 
capacity  and  the  transmission  unit  is  either  a  byte  or  a 
word. 

2.  The  Software  Interface 

The  host  software  is  written  by  Amperlf  Corporation 
of  Chatsworth,  California.  This  software  consists  of  the 
host-driver  routines  whose  primary  purpose  is  to  parse  the 
queries  and  to  translate  them  into  the  database  machine 
language.  Finally,  the  host  handles  the  communications 
protocol  between  the  database  machine  and  itself, 

B.  THE  BACKENO  DATABASE  MACHINE 

1.  A  Modular  Design 

The  database  machine  which  interfaces  with  the  host 
is  an  IDM  500  manufactured  by  Britton-Lee  Incorporated  of 
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Los  Gates,  California.  IDM  500  is  being  marketed  by  Amcerlf 
Corporation  as  an  RDM  llOO,  it  is  a  modular,  expandable, 
and  microprocessor-based  system  organized  around  a  central 
high-speed  bus.  The  separate  modules  are  functionally 
oriented.  The  RDM  llOO  employs  the  relational  database 
eodel  which  will  be  discussed  in  detail  in  Section  v. 

The  database  processor  (Z8000-based  microprocessor) 
supervises  and  manages  all  system  resources.  This  processor 
executes  most  of  the  software  in  the  system. 

The  database  accelerator  is  an  optional,  high-speed 
processor  with  an  instruction  set  specifically  designed  to 
perform  certain  relational  database  functions.  The 
accelerator  has  a  three-stage  pipeline  which  executes 
instructions  at  up  to  10  MIPS.  This  processor  can  initiate 
disk  activity  and  can  process  data  at  disk  transfer  rates. 
The  accelerator  and  the  RDM  llOO  software  are  so  configured 
that  the  most  frequently  occurring  database  work  is 
performed  by  the  accelerator  under  the  direction  of  the 
database  processor. 

The  cache  memory  (l.e,,  main  memory)  of  RDM  1100  is 
composed  of  64K-blt  chips  of  dynamic  RAM.  It  may  be 
expanded  to  a  maximum  of  six  megabytes.  This  cache  is 
utilized  tor  RDM  1100  system  code,  disk  caching,  indices, 
and  user  commends. 

Disk  Controller  modules  may  be  expanded  from  one  to 
four.  Each  controller  can  manage  from  one  to  four  disk 
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drives.  The  disk  controller  iroves  date  between  the  disks 
and  the  cache  memory.  and  is  designed  to  work  with  the 
accelerator.  An  optional  tape  control  module  supports  up  to 
eight  tape  drives  which  can  be  used  for  direct,  disk-to-tape 
backup,  data,  and  software  loading. 

RDM  1100  and  the  host(s)  communicate  with  each  other 
via  ROM  1100's  host-interface  module.  This  module  accepts 
commands  from  one  or  more  hosts,  and  acts  on  those  commands 
accordingly.  Each  host-interface  module  can  handle  up  to 
eight  hosts  and  a  maximum  of  eight  host-interface  modules 
can  be  made  available  on  RDM  lioo.  Hence,  a  maximum  of  64 
hosts  can  be  accommodated  by  RDM  lioo.  In  addition  to 
communications  handshaking  protocols,  the  interface  module 
performs  necessary  error  checks  and  causes  the  host  to 
retransmit  any  Information  block  m  which  an  error  is 
detected.  CRef.  41 

2.  The  System  Configuration 

In  the  configuration  described  above  Cl.e..  the 
connection  of  the  host  and  the  database  machine  with  an  I/O 
channel),  the  database  machine  Is  called  a  backend  database 
machine.  The  term,  'backend',  is  used  in  this  context  to 
refer  to  a  special-purpose  machine  operating  as  a  peripheral 
device  on  one  or  more  host  systems.  As  previously 
mentioned,  the  use  of  the  baekend  macnlne  can  siqnlficantly 
reduce  the  required  CPU  time  for  data  manipulation  by  the 
host.  Further  advantages  are  realized  through  freeing  disk 
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space  on  the  host  and  the  reduction  of  Z/0  cycles;  thus 
releasing  the  CPU  to  perform  ether  functions  necessary  fer 
the  proper  operation  of  the  system  and  execution  of 
applications  programs. 

The  performance  of  RDM  llOO  is  highly  dependent  on 
the  available  hardware  configuration.  other  performance 
Issues  such  as  indexing  and  data  positioning  are  dependent 
on  the  software  developed.  Ihe  hardware  configurations  are 
discussed  below  and  the  software  issues  are  discussed  in 
Section  IV. 

Four  test  conflguratio.ns  are  used  during  the  course 
of  this  research.  The  initial  configuration  is  of  one-half 
megabyte  of  cache  without  the  accelerator.  This 
configuration  will  not  be  marketed  by  Amperlf,  but  is  tested 
for  the  purpose  of  comparison.  The  next  test  configuration 
is  of  one-megabyte  of  cache  with  the  accelerator.  Following 
it,  a  two-megabyte  cache  with  the  accelerator  is  tested. 
Finally,  the  accelerator  is  removed  from  the  configuration. 
The  configuration  is  tested  with  only  the  two-megabyte 
cache.  The  standard  commercial  configuration  is  with  one- 
megabyte  of  caehe.  The  accelerator  is  an  optional  feature. 
For  specific  Information  on  the  performance  measurements, 
the  reader  is  directed  to  [Ref.  2]  and  (Ref.  3). 
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A.  AN  INTRODUCTION  TC  THE  LANGUAGE 

In  addition  to  tha  hardware  and  software  to  support  the 
hoat/baclcend  interface*  Amperif  also  provides  a  language  for 
requesting  information  or  operations  on  data  from  the 
backend  database  aachine.  This  language  is  called  the 
Relational  Query  Language  (RQL).  The  language*  being  tne 
only  interface  for  the  user  and  database  administrator 
(DBA)*  is  the  sole  aeans  by  whieh  the  capabilities  and 
limitations  of  the  backend  are  known  to  the  user  and  DBA, 
Therefore*  a  discussion  about  the  facilities  of  RQL  win  be 
presented. 

This  section  defines  two  major  command  groups  available 
in  RQL.  The  eatanotatlon  used  in  the  command  syntax 
consists  of  the  symbols  described  below. 


(  ) 
t  1 


<  > 


<  > 


used  as  delimiters  in  RQL 

used  to  indicate  anything  optional  inside 

the  square  brackets 

used  to  denote  a  choice  of  the  word  eltner 
before  or  after  the  bar 

used  to  specify  zero  or  more  occurrences  of 

anything  in  the  curly  brackets 

used  as  metasymbols  to  denote  a  construct  in 
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RQL  with  the  name  ef  the  construct  between 
the  metasymtols 

All  other  words  In  RQL  ere  key  words  end  must  appear 
literally  [Ref.  5].  In  the  retraining  sections  key  words  are 
capitalized.  In  sections  explaining  the  commands.  an 
abbreviated  syntax  of  each  command  followed  by  an 
explanation  of  the  command  is  provided.  Ihls  Information  Is 
taken  from  [Ref.  5]  and  (Ref.  6J. 

B.  DATA  DEFINITION  COMMANDS 

In  RQL  the  commands  are  presented  without  reqard  to 
function.  However.  In  most  database  books,  (e.g..  [Kef.  7] 
and  [Ref.  8]).  there  Is  a  distinction  between  the  data 
definition  language  and  the  data*  manipulation  lanquage. 
Although  this  distinction  Is  not  made  In  RQL.  it  provides  a 
logical  division  of  the  majority  of  commands  and  facilitates 
the  understanding  of  the  commands.  The  data  definition 
language  consists  of  those  commands  which  are  used  for  the 
description  of  database  objects. 

Data  can  be  represented  In  seven  different  types  In  RDM 
1100.  The  two-character  specifications  available  are  for 
the  compressed  (c)  and  uncompressed  (uc)  character  string 
with  the  user  providing  a  maximum  length,  up  to  255 
characters.  The  difference  Is  that  the  compressed  character 
string  is  not  stored  with  trailing  blanks.  Integers  can  be 
declared  with  three  different  byte  sizes  namely,  l.  2.  or  4. 


The  byte  size  of  an  attribute  limits  the  precision  which  can 
be  accommodated  In  the  attribute  values.  Finally, 
floating-point  numbers  can  also  be  expressed  as  compressed 
(f)  or  uncompressed  (uf).  The  range  provided  by  these  two 
forms  Is  identical  and  of  31  significant  digits.  As  In 
character  strings  the  user  must  specify  the  number  of 
significant  digits  desired,  The  difference  Between 
compressed  and  uncompressed  floating  point  is  the 
suppression  of  leading  and  trailing  zeros  in  tne  compressed 
floating  point.  Compression  Is  a  feature  designed  to  reduce 
the  storage  requirement  In  the  database,  ine  following 
declaration  Is  an  example  of  the  use  of  attribute  types: 

name  *  c25 ,  salary  *  ufB,  age  *  11 ,  address  «  c200. 

This  example  establishes  four  attributes:  'name'  whose 
values  can  each  consist  of  up  to  25  characters,  'salary' 
whose  values  are  floating-point  numbers  each  of  which  is  of 
eight  significant  digits,  'age'  whose  values  are  one-byte 
integers,  and  'address'  whose  values  are  character  strings 
of  up  to  200  characters  each.  Notice  'name'  and  'address' 
are  designated  as  compressed  and  therefore  trailing  blanks 
of  their  values  are  not  stored. 

1.  To  Create  a  Database 

CREATE  DATABASE  <naire>  [WITH  <optlons>] 
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This  command  is  used  to  establish  a  database  which 
will  be  referred  to  by  the  user»speciiled  name.  The  two 
options  provided  are  DISK  end  demand.  disk  allows  the 
specification  of  one  or  mere  disks  on  which  the  database 
will  be  stored  Ce,g,f  01SK  ■  #sys#).  demand  specifies  the 
number  of  2K»byte  blocks  to  be  allocated  for  the  database. 
If  the  database  grows  beyond  the  allocated  clocks,  it  may  oe 
extended  with  the  following  command: 

EXTEND  DATABASE  <naire>  WITH  <optlons> 

The  options  are  identical  to  the  options  of  CREATE  database, 
2.  lo  Create  a  Relation 

CREATE  RELATION  <naire>  (<attribute  name>  »  <format> 
4,  <attrlbute  name>  a  <format>))  (with  <options>J 

The  create  command  is  used  to  establish  the  schema 
tor  a  relation.  An  empty  relation  is  set  up  in  the  database 
when  the  commend  is  executed  with  the  actual  specification 
of  the  attributes  in  parenthesis  being  given  as  depicted  in 
the  example  of  data  types  above.  One  possible  option  whlcn 
may  be  declared  is  LOGGING.  This  option  causes  every  cnange 
to  the  relation  to  be  logged  in  tne  database  transaction 
log.  This  feature  is  extremely  Important  to  maintain  the 


consistency  and  integrity  of  the  relation  when  system 
recovery  must  be  initiated. 


CREATE  [UNIQUE]  (NONCLUSTERED  I  CLUSTERED]  INDEX 

CCN]  <ooject  name>  (<attribute>  (,  <attribute>> ) 

An  index  on  on  attribute  of  a  relation  provides  a 
direct  aeeess  to  tne  attribute  values  in  the  relation.  A 
unique  index  on  an  attribute  requires  all  attribute  values 
to  be  different.  There  are  two  primary  differences  between 
clustered  and  nonelustered  indices,  A  clustered  index  is 
nondense  (l.e.,  one  entry/blcck)  whereas  the  nonclustered 
index  is  dense  (l.e.,  one  entry/tuple).  The  second 
difference  relates  to  the  storage  of  data.  Aithougn  the 
nonclustered  index  does  not  affect  the  placement  of  data, 
the  clustered  index  requires  tne  tuples  of  the  relation  to 
be  stored  in  the  order  of  the  attrloute  values. 
Consequently,  only  one  clustered  index  may  be  created  for  a 
relation  whereas  250  nonclustered  indices  may  be  defined  for 
the  sane  relation.  For  performance  data  on  operational 
enhancement  provided  by  indices,  see  (Ref.  2]  and  (Ref.  3], 
4.  to  Create  a  View 

CREATE  VIEW  <vlew  name>  (<target  llst>) 

(WHERE  <quelif ication>] 

The  CREATE  VIEW  command  establishes  a  virtual 
relation,  l.e.,  there  is  no  storage  of  tuples  associated 


with  the  view,  a  view  is  a  composite  relation  (without  its 


own  tuples)  of  attributes  froir  other  relations  or  views. 
The  target  list  Is  the  list  of  attributes  desired  from  the 
other  relations  or  views.  Finally,  the  Qualification  allows 
the  user  to  restrict  tne  quantity  of  data  In  the  view  to  a 
particular  category  and  to  provide  necessary  llnKages 
between  the  relations  or  views. 


foDej 


a  Stored  Command 


DEFINE  <stored  command  raire> 
<cosi»and>  <<coirirand>> 
END  DEFINE 


In  RQL  the  DEFINE  command  provides  a  mechanism  for 
creating  subroutines  In  the  database  machine.  Stored 
commands  may  have  parameters  or  be  parameterless.  Tne 
<eomaand>  can  be  an  APPEND.  DELETE.  REPLACE,  retrieve,  etc. 
(to  be  discussed  later).  There  are  two  advantages  to  stored 
commands.  One  la  that  It  relieves  the  operator  of  retyping 
a  frequently  employed  command  and  allows  the  DBA  to  provide 
a  a  simplified  method  for  invoking  complex  queries.  The 
second  and  perhaps  most  Important  advantage  Is  the 
performance  enhancement.  Since  the  stored  command  exists  In 
the  database  with  all  addresses  of  cited  relations  resolved, 
the  communications  between  the  host  and  the  baekend  machine 
is  reduced  to  passing  an  EXEC  token  and  the  command  name. 
Examples  of  stored  commands  are  provided  In  Appendix  A. 
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®*  IQ  Destroy  a  Database 

DESTROY  DATABASE  <name> 

The  DESTROY  DATABASE  command  eliminates  the  entire 
database  by  removing  all  linkages  from  RDM  1100  and  freeing 
the  storage  space. 

7.  To  Destroy  an  Object 

DESTROY  <ob ject  name> 

This  command  eliminates  existing  relations, 
established  views  or  stored  commands  from  the  database.  The 
space  freed  by  the  command  is  reusable  by  the  database.  As 
indicated  previously,  views  and  stored  commands  depend  on 
existing  relations  or  views.  These  underlying  objects  are 
said  to  have  dependencies.  An  object  which  has  dependencies 
cannot  be  destroyed  without  first  destroying  the  dependent 
object.  This  does  not  apply  to  indices,  wnlcn  are 
automatically  destroyed  when  the  relation  is  destroyed. 

8.  To  Destroy  an  Index 

DESTROY  (NONCLUSTERED  I  CLUSTERED]  INDEX  [ON] 

<object  name>  ^attribute  name> 

(,  <attrlbute  name>>] 

If  an  index  is  unnecessary  or  the  overhead 
associated  with  keeping  an  index  is  to  high,  the  index  may 
be  deleted  from  a  database  by  the  DESTROY  INDEX  command.  In 


addition  to  the  object  noire*  the  user  must  also  specify  the 
exact  attributes  of  the  index  fer  the  purpose  of  avoiding 
any  ambiguity. 

C.  DATA  WANIPULATICN  COWHANDS 

The  data  manipulation  language  is  that  subset  of  RQL 
commands  which  allows  the  user  to  access,  update,  and 
retrieve  the  data  stored  in  the  database. 

1*  To  Retrieve  Data 

RETRIEVE  [UNIQUE]  (<target  llst»  [ORDER  [BY]  <order 
specif icatlen>  ( s A  I  D] 

{,  <order  specif ication>  ( s A  I  D]>] 

(WHERE  equal lflcation>] 

The  RETRIEVE  command  Is  the  most  commonly  emoloyed 
command  In  RQL.  Xt  Is  the  means  by  which  data  Is  extracted 
from  the  database  and  returned  to  the  user.  The  target  list 
provides  the  user  with  the  facility  to  reduce  the  amount  of 
data  by  limiting  the  number  of  attribute  values  requested. 
The  format  for  the  target  list  1st 

relation.name.attrlbute.name 

[,  relation.name.attrlbute.name] . 

This  list  of  attributes  can  be  from  one  or  more  relations. 
To  reduce  duplicate  Information,  unique  can  be  employed. 
The  order  specification  dictates  the  order  (i.e., 
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alphabetic,  numeric  or  alphanumeric  order)  In  which  the  data 
is  to  be  sorted.  Finally,  the  Qualification  allows  the  user 
to  specify  predicates  which  the  data  must  satisfy  and  to 
require  linkages  between  relations.  These  predicates  and 
linkages  reduce  the  number  of  tuples  retrieved. 

2.  To  Append  sew  Tuples 

APPEND  ETC]  <relatlon  name>  (<vaiue  list>) 

(WHERE  (<quallf lcatlon>) ] 

The  APPEND  command  allows  the  user  to  add  tuples  to 
a  specific  relation.  The  value  list  must  specify  the 
attribute  names  and  attribute  values  with  an  equality  sign 
in  between.  Unlisted  attribute  values  In  the  value  list  are 
assigned  default  values  (l.e.,  blanks  for  characters  and 
zeros  for  numerals), 

3.  To  Replace  Attribute  Values 

REPLACE  <relatlon  name>  (<value  llst>) 

(WHERE  <quallf lcatlon>) 

REPLACE  provides  the  facilities  for  updating  values 
stored  In  the  database.  Although  it  can  only  chanqe  one 
relation  at  a  time,  the  number  of  attribute  values  Is  not 
limited.  Further,  more  than  one  relation  can  be  accessed  to 
calculate  what  Is  to  be  updated.  Although  a  view  name  may 
be  used  In  place  of  tne  relation  name  In  REPLACE  and  APPEND 
commands,  the  numerous  restrictions  on  the  acceptability  of 
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this  procedure  makes  It  alirost  impotent  and  at  best 


Infeasible. 


4.  To  Delete  Tuples 


DELETE  <relation.nafre>  INHERE  <qualif lcatlon>J 


This  command  Is  used  to  remove  one  or  more  tuples 
from  a  relation.  Zf  a  WHERE  clause  Is  not  specified  then 
all  tuples  will  be  deleted, 

5.  To  Aggregate  attribute  Values 

There  are  six  scalar  aggregates  supplied  In  rql 
which  may  be  applied  to  one  or  more  attribute  values.  These 
aggregates  return  a  single  value,  known  as  tne  scalar,  to 
the  user.  The  results  of  *1N  and  wax  are  tne  smallest  ana 
largest  attribute  values  found  for  tne  attribute, 
respectively.  sum  and  AVG  provide  the  arithmetic  total  and 
mean  of  the  respective  attribute  values,  count  returns  the 
number  of  occurrences  of  the  specific  attribute  value,  any 
Is  used  to  test  for  the  existence  of  a  specific  attribute 
value.  This  Is  accomplished  by  appiylna  any  to  a  condition 
(e.g«,  ANY  a  (relation-name. attribute. name  =  value)).  if 
the  condition  Is  true  for  at  least  one  attribute  value  a  ' 1 ' 
is  returned,  *0*  otherwise.  Any  scalar  aggregate  can  have  a 
predicate  (qualification)  and,  since  it  returns  a  single 
value,  can  be  used  anywhere  a  scalar  value  Is  permissible  In 
an  expression  or  other  predicate,  unique  can  be  used  witn 
COUNT,  SUN,  and  AVG  to  avoid  including  duplicate  entries  In 
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the  computed  scalar  value.  For  example,  COUNT  UNIQUE  can  be 
used  on  a  personnel  database  to  retrieve  the  number  ot 
different  states  (assuming  birthplace  is  an  attribute) 
represented  by  the  employees  place  of  birth  without  regard 
to  the  actual  number  of  employees  from  each  state,  lhese 
scalar  aggregates  are  useful  in  providing  statistics  about 
the  database  and  in  isolating  tuples  whose  attribute  values 
are  numeric.  For  example,  a  query  can  be  composed  to 
provide  a  list  of  attribute  values  such  that  each  value  is 
greater  than  the  average  of  the  values. 

6*  Aggregate  Functions 

The  term  'function*  is  misleading  when  used  In  this 
context  since  the  results  ot  applying  an  aggregate  function 
is  a  list  of  scalars.  Although  this  is  not  the  generally 
accepted  concept  of  a  function  (returning  a  single  value)  in 
the  literature,  it  will  continue  to  be  used  in  this  thesis. 
Aggregate  functions  are  used  in  conjunction  wi-.n  the  'group 
by'  (BY)  clause.  This  clause  provides  a  oartltlon  of  the 
attribute  values.  The  partitioned  values  can  then  oe  used 
as  arguments  ot  an  aggregate  function.  There  can  be  more 
than  one  aggregate  function  in  a  query,  and  aggregate 
functions  may  be  nested.  Additionally,  aggregates  may 
appear  in  both  the  target  list  and  qualification.  An 
example  of  the  application  of  an  aggregate  function  can  be 
found  in  Section  v. 
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The  aggregate  functions  provide  the  computational 


power  of  RGl,  without  the  functions  there  would  be  no  easy 
Method  of  dividing  attribute  values  into  sets  and  performing 
tests  or  computations  on  these  value  sets.  Further,  the  use 
of  aggregate  functions  relieves  the  user  from  creating 
numerous  temporary  relations  and  from  manipulating  them 
individually  for  the  desired  result.  For  example,  in  a 
personnel  relation  with  salaries  and  department  numbers  as 
attributes,  it  may  be  desirable  to  compute  the  average 
salary  of  eaeh  department.  This  is  easily  accomplished  by 
the  use  of  the  aggregate  function  in  the  target  list  as 
follows! 


answer  »  AVG  (salary  By  dept.no). 

If  this  capability  were  not  available,  some  other  form  of 
partitioning  would  be  required  to  support  the  query.  One 
might  provide  a  separate  retrieve  for  each  department 
number,  form  a  temporary  relation  for  the  retrieved  salary 
figures,  and  average  on  the  newly  formed  relation 
separately. 

7.  Strinq-maniculatlon  Functions 

In  order  to  maintain  the  simple  format  of  a 
relational  system  and  yet  provide  the  eaoablllty  to  obtain 
data  based  on  partial  or  combined  attributes.  RQL  includes 
three  string  manipulation  functions.  The  most  useful  of  the 
three  tor  the  user  appears  to  be  pattern  matching.  By  using 
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symbols  to  represent  any  nuirfeer  of  characters,  tuples  having 
a  desired  Internal  pattern  in  a  specific  attribute  can  be 
selected.  Again,  consider  a  personnel  relation  with  an 
attribute  of  date  of  birth.  The  pattern  matching  function 
could  be  used  to  provide  a  list  of  all  personnel  born  in  a 
particular  month.  Pattern  matening  applies  only  to 
characters  and  Is  only  used  In  predicates. 

The  other  two  functions  are  CONCAT  and  SUBSTRING. 
These  functions  can  be  used  with  character  or  binary 
attributes,  CGNCAT  requires  two  string  arguments,  strips 
all  trailing  blanks  from  both  strings  and  concatenates  the 
second  string  to  the  first.  The  SUBSTRING  function  requires 
a  starting  position  In  the  string,  a  lengtn  to  define  the 
number  of  characters  desired,  and  the  attribute  on  which  to 
perform  the  operation.  For  an  example  of  SUBSTRING 
employment,  see  Appendix  A. 

0.  System  Supplied  Functions 

There  are  three  categories  of  system  supplied 
functions  available  in  RQL,  These  provide  Information  about 
the  database  and  host,  cross  reference  of  system  assigned 
identification  numbers  to  associated  character  strings,  and 
data  type  conversions. 

The  first  group  of  functions  is  parameterless  and 
provide  general  information  about  the  host  and  database.  For 
example  a  user  may  request  the  name  of  the  database 
(OATABASENAME  ()],  the  time  or  date  CGETTIME  ()  or  GETDATfc 


()],  the  attached  host  [HOST  ()],  the  identity  ot  the  DBA 
[DBA  03,  or  who  is  executing  a  command  [userid  ()]. 

The  second  group  of  functions  is  useful  in  providing 
Information  in  a  meaningful  form  to  tne  user.  There  are 
three  self-explanatory  commands  in  this  group  [REL.ID 
(relation  name),  rel.name  (relation  ID),  and  field.nane 
(relation  ID,  attribute  ID)).  These  translations  are  used 
extensively  In  Appendix  A. 

The  last  group  provides  the  capability  to  convert 
expressions  (exp)  from  one  data  type  to  another.  For 
example,  a  user  may  convert  an  expression  to  a  l- ,  2-  or  4- 
byte  Integer  [INTI  (exp),  INT2  (exp)  or  INI4  (exo)j,  a 
binary  number  (BIN  (exp)],  or  a  floating-point  number  CFLCAT 
(length,  exp)].  The  expression  can  be  any  one  of  the  other 
types  listed  as  veil  as  string  and  binary  coded  decimal  in 
there  legal  forms  (e.g.,  compressed  and  uncompressed). 

D.  EXPRESSING  THE  RELATICNAL  OPERATIONS  IN  THE  QUERY 
LANGUAGE 

The  power  of  a  relational  query  language  is  usually 
measured  by  Its  ability  to  perform  the  operations  specified 
In  relational  algeora  or  relational  calculus.  Since  the 
equivalence  of  the  two  has  been  demonstrated  [Ref.  81,  the 
relational  algebra  will  be  used  for  comparative  purposes 
without  loss  of  generality.  It  should  oe  noted  that  RQL  is 
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probably  best  characterized  as  a  domain-based  relational 
calculus. 

The  relational  algebra  supports  four  traditional  set 
operations  (Union,  intersection.  Difference,  and  Cartesian 
Product)  and  four  special  relational  operations  (Selection, 
Projection,  Join,  and  Division).  All  eight  operations  will 
be  defined  and  an  example  of  each  In  RQL  will  oe  provided. 
In  the  examples  the  term,  relation. name,  will  be  abbreviated 
to  'rel*  and  the  term,  attribute.name,  to  'attr#. 

1.  The  selection  Operation 

The  selection  operation  provides  a  subset  of  tuples 
in  a  relation  which  satisfy  a  given  qualification.  All 
attribute  values  of  every  tuple  satisfying  the  predicate  are 
included  in  the  subset.  POL  provides  an  ALL  keyword  which 
simplifies  the  selection  operation  oy  avoiding  the 
enumeration  of  every  attribute  In  the  target  list. 

RETRIEVE  UNIQUE  (rel.ALL)  WHERE  <qualif lcation> 

2.  The  Projection  Operation 

Projection  Is  used  to  reduce  the  number  of  attribute 
values  In  the  tuples  which  make  up  the  selected  subset.  In 
addition  to  limiting  the  nuiroer  of  attribute  values  in  a 
tuple,  the  projection  operation  also  deletes  duplicate 
tuples  from  the  subset.  Deleting  duplicates  can  be  enforced 
by  using  the  optional  keyword  UNIQUE,  Projection  in  RQL  Is 
a  function  of  the  target  list  lr  the  retrieve  eomrrand.  A 


qualification  iray  be  used  to  reduee  the  number  of  tuples  as 
in  selection.  To  reiterate,  selection  reduces  the  number  ot 
tuples  whereas  projection  reduces  the  number  of  attribute 
values, 

RETRIEVE  UNIQUE  (rel.attri,  rel,attr2,  .,,,  attrn) 
WHERE  <qualif lcatlon> 

3,  The  Join  Operation 

The  join  operation  say  be  performed  on  any  number  of 
relations  whose  attributes  are  defined  over  a  common  domain. 
The  result  of  th*e  Join  is  a  new,  higher-degree  relation. 
Each  tuple,  in  the  resultant  relation,  is  formed  by 
concatenating  tuples  from  the  source  relations  whose 
attribute  values  satisfy  the  qualification, 

Ihere  are  different  qualifications  and  therefore 
different  joins.  The  equl-joln  is  formed  over  an  equality 
predicate.  The  inequality  join  is  formed  over  an  inequality 
predicate  with  an  operator  such  as  <,  >,  <»,  >»  or  Is.  The 
following  is  an  example  of  an  equl-joln;  the  other  joins  can 
be  realized  by  manipulating  the  target  list  (natural  join) 
or  predicate  (inequality  join),  aeeordinaly. 

RETRIEVE  UNIQUE  (rell.ALL,  rel2 • ALL ) 

WHERE  reli, jolnattr  *  re!2, Joinattr 


The  division  operation  is  defined  for  two  relations 
in  which  the  divisor  relation  has  a  degree  less  than  the 
degree  of  the  dividend  relation,  Tne  resultant  relation  has 
a  degree  equal  to  the  difference  of  the  deqrees  of  the  two 
relations.  The  division  operation  is  demonstrated  using 
relations  rail  and  rel2  and  dividing  rell  by  rei2  where  the 
degrees  of  rell  and  rel2  are  ir  and  n  respectively  with  m  >» 
n.  The  resultant  relation  consists  of  the  first  (m-n) 
attribute  values  for  each  tuple  in  the  dividend  ,  rell,  such 
that  every  tuple  in  the  divisor#  rel2#  exists  as  the  last  n 
attribute  values  of  the  uniquely  determined  partial  tuples 
[identical  first  (m-n)  attribute  values!  in  rell.  For 
example  if  a  relation  X  has  tuples  abed#  abef,  becd,  and 
abab#  and  relation  Y  has  tuples  cd  and  ef  then  x  divided  ey 
Y  would  be  the  relation  containing  the  tuple  ab.  The  tuple 
ab  would  exist  in  the  resultant  relation  since  abed  and  abef 
are  in  X.  However#  the  tuple  be  would  not  appear  since  beef 
is  not  in  X. 

RETRIEVE  (rell.attrl#  reil,attr2#  ...  #  rell .attr(m-n) ) 
WHERE  COUNT  Crel2.attri)  a 

COUNT  (rell.attrl  by  rell.attrl# 

reil,attr2#  •••#  reii.attr (m-n) 
WHERE  rell.attrCm-n+i)  a  rel2.attrl 

anc  reli.attr(m-n+2)  a  rel2.attr2 
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AND 

AND  rell.attrm  a  rei2.attrn) 

5.  The  Union  Operation 

Union  is  the  traditional  set-theoretic  definition  of 
union  with  the  additional  constraint  of  requiring  the  two 
relations  to  be  union-compatible.  Unlon-coirpatibillty 
stipulates  that  the  two  relations  trust  be  of  the  saire  degree 
and  the  corresponding  attribute  values  must  be  taicen  from 
the  same  domain  (e.g.,  rell.attrk  and  rel2,attric  must  be 
defined  over  the  same  domain).  The  union  of  two  union- 
compatible  relations  is  the  set  of  all  tuples  belonging  to 
either  relation  or  both  relations.  Note  that  duplicates  are 
not  automatically  eliminated  but  a  RETRIEVE  unicue 
(unlon.rel. ALL)  can  be  executed  after  the  following  example 
to  display  the  union, 

RETRIEVE  INTO  union.rel  (reil.ali) 

WHERE  <quallf lcatlon> 

append  TO  unlon.rel  (attrl  a  rel2.attri, 
attr2  ■  rei2.attr2,  ....  attrlast  »  rel2.attrlast) 
WHERE  <quallf ication> 

6.  The  Intersection  Operation 

Intersection  is  only  defined  for  union-compatible 
relations.  The  resultant  relation  is  comprised  of  tuples 
whleh  exist  identically  in  both  of  the  relations. 
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RETRIEVE  UNIQUE  (rell.all) 


WHERE  rell.attrl  *  rei2.attrl 

AND  rell.attr2  *  r«12,attr2 

AND  • • • 

AND  rell.attrlast  *  rel2,attrlast 

7*  The  Cartesian-Product  Cceratlon 

Given  two  relational  rail  and  rel2r  of  degree  ir  and  n 
respectively i  the  Cartesian  product  Is  the  set  of  all  tuples 
of  degree  (n+n)  formed  by  taking  the  first  tuple  in  rell  and 
concatenating  to  it  all  tuples  (one  at  a  time)  in  rel2.  This 
process  is  then  repeated  tor  the  second  tuple  in  rell  until 
all  tuples  in  rell  have  been  concatenated  with  every  tuple 
In  rel2. 


RETRIEVE  UNIQUE  (rail. all,  rel2.all) 

S.  The  Difference  Operation 

The  difference  of  two  union-compatible  relations  is 
the  set  of  tuples  in  the  first  relation  but  not  in  the 
second, 

RETRIEVE  UNIQUE  (rail. ALL) 

WHERE  0  *  ANY  (rell.attrl  BY  rell.attrl 
WHERE  rell.attrl  ■  rel2.attrl 
AND  ... 

AND  rell.attrlast  *  rel2,attrlast) 
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This  query  requires  eeeh  tuple  In  rell  to  be 
compared  with  every  tuple  in  rel2.  In  the  above  example,  it 


is  assumed  that  rell.attrl  Is  the  Key  for  the  relation.  In 
the  event  a  relation  has  a  composite  Key,  tne  rell.attrl 
followlnq  the  BY  can  be  replaced  by  a  linear  list  of 
attributes  comprising  the  Key. 
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IV. 


The  role  of  CBA  Is  to  establish  the  database  and  to 
ensure  that  the  database  systee  is  responsive  to  the  user's 
performance  requirements  and  information  needs.  Although 
the  diseusslon  of  DBA  will  use  ROM  1100  as  the  target 
system,  the  facilities  described  and  DBA  support  required 
should  be  applicable  to  any  relational  database  management 
system,  in  particular#  the  amount  of  DBA  support  required 
does  not  depend  on  a  particular  system.  If  tne  system  does 
not  provide  certain  facilities#  DBA  will  be  required  to 
reformat  and/or  extract  the  information  from  the  database  to 
satisfy  the  users  information  needs.  Finally#  DBA  will  be 
referred  to  as  an  Individual!  however,  the  functions  can  be 
the  responsibility  of  a  group  of  people. 

This  section  will  discuss  the  functions  and 
qualifications  of  DBA  in  the  areas  of  database  environment, 
database  design#  system  services#  user  services#  security# 
and  performance  enhancement.  For  each  area#  a  generalized 
statement  concerning  DBA  functions  and  qualifications  win 
be  provided;  then  a  specific  description  of  the  function  in 
the  RDM  1100  environment  will  fellow.  RDM  1100  feature 
which  supports  it. 
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A.  THE  DATABASE  SYSTEM  ENVIRONMENT 

A  software  database  management  system  Is  designed  to 
support  a  single  database  on  a  general-purpose  computer* 
The  advantage  of  a  backend  relational  database  machine  Is 
the  support  which  can  be  proviaed  to  multiple  hosts  and 
multiple  databases*  The  existence  of  multiple  databases  on 
a  single  machine  creates  two  levels  of  management.  Level 
one,  the  system  DBA,  Is  primarily  concernea  with  machine- 
wide  performance  and  establishing  authorizations  for  the 
database  DBAs •  Level  two,  the  database  DBAs ,  is  concerned 
with  the  operational  data  In  the  individual  databases.  DBA 
and  system  DBA  should  be  knowledgeable  In  the  areas  outlined 
above  to  ensure  efficient  and  rellaole  database  performance* 

In  RDM  1100  the  system  DBA  has  control  of  a  dataease 
called  the  system  database*  Certain  commands  such  as 
creating  and  destroying  databases  can  be  Issued  only  from 
the  system  database.  when  a  new  database  is  created  the 
Individual  Issuing  the  CREATE  DATABASE  command  will  be  DBA 
for  that  database.  In  this  thesis  DBA  will  refer  to  the 
level-two  DBA  unless  otherwise  indicated. 

B.  THE  DATABASE  DESIGN  -  THE  PHYSICAL  AND  CONCEPTUAL 

SCHEMAS 

As  alluded  to  above,  DBA  has  numerous  areas  of  concern. 
The  second  area  to  be  addressed  is  the  database  design. 
This  topic  describes  the  design  of  the  physical  schema  and 


the  conceptual  schema.  A  schema  is  simply  a  plan  for  a 
particular  level  of  the  database.  The  third  level,  external 
schema,  will  be  addressed  In  Section  IV  C. 

The  physical  schema,  also  called  the  internal  schema,  is 
a  plan  for  the  actual  storage  of  data  on  the  physical 
devices  available  to  the  database.  In  RDM  1100  each  disk  is 
divided  Into  zones  of  180  2K-tyte  blocks.  The  first  block 
In  each  zone  Is  reserved  for  a  directory  to  the  contents  of 
that  block.  The  number  of  blocks  required  for  a  relation  is 
dependent  on  the  number  of  tuples  and  the  length  of  the 
tuples.  Since  the  physical  schema  is  a  function  of  the 
database  system,  the  major  Issue  from  the  DBA  perspective  is 
whether  the  system  allows  the  location  of  data  and  indices 
to  be  explicitly  specified. 

The  conceptual  schema  Is  the  logical  plan  normally 
associated  with  the  entire  'organizational  view'  and 
Instituted  by  DBA.  As  the  physical  schema  is  comprised  of 
the  actual  location  and  storage  structure  of  the  entire 
database,  the  conceptual  schema  includes  the  names  of  all 
relations,  Indices,  and  data  dictionary  entries  in  the 


The  primary  query  language  subset  used  to  define  the 
conceptual  and  physical  schemas  is  tne  data  definition 
language.  The  mapping  between  the  physical  and  conceptual 
schema  is  performed  by  the  database  system.  This  mapping  is 
built  as  the  objects  are  made  known  to  the  database  system. 
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In  RQL  the  CREA1E  <objeet>  commands  are  the  primary 
commands  employed  to  specify  the  conceptual  and  physical 


schemas.  The  database  system  will  construct  a  data 
dictionary  for  each  object.  This  includes  making  the  object 
known  to  the  system,  reservino  appropriate  storage,  and 
describing  the  appearance  of  the  object  (e.g.,  number,  size, 
and  type  of  attributes).  In  order  to  design  the  physical 
and  conceptual  schemas,  CBA  must  know  the  organizational 
structure  and  must  understand  database  normalization,  the 
database  system  architecture,  and  the  concepts  of  data 
sharing  and  ownership. 

1,  Organizational  Structure 

Since  OBA  is  responsible  for  ensuring  that  the 
database  reflects  the  'real  world'  of  the  organization  It 
supports,  there  Is  ample  justification  for  a  good  working 
knowledge  of  the  organization.  The  objective  is  to  develop 
a  plan  which  will  accurately  reflect  the  organizational 
requirements  without  a  need  to  continuously  redesign  the 
database.  Although  It  is  tempting  to  limit  the  application 
to  one  functional  area  like  persennei,  DBA  must  be  aware  of 
the  relationships  between  the  personnel  and  other  entities 
in  tne  organization,  without  a  total  organizational  picture 
D8A  will  ultimately  be  faced  with  redesign  to  meet  the 
organization's  needs. 


2*  Normalization 


In  order  to  enhance  database  reliability  and  reduce 
redundancy#  a  solid  foundation  In  relational  database  deslon 
principles  Is  required,  Cne  extremely  important  aspect  Is 
the  DBA's  understanding  of  normalization.  Cnee  a  specific 
normal  form  Is  established  for  a  database#  DBA  must  realize 
the  possible  Implications  of  deviations  from  a  tnls  normal 
form  and  should  document  the  exceptions.  Normal  forms  are 
not  specifically  discussed  in  this  thesis  and  the  reader  is 
directed  to  tRef,  7]  for  more  information. 

The  RDM  lloo  system#  like  most  existing  relational 
systems#  requires  only  that  all  relations  be  In  first  normal 
form.  This  normal  form  stipulates  that  each  attribute  value 
In  a  relation  must  be  atomic.  That  Is.  the  value  is  not 
decomposable.  Further#  there  Is  only  a  single-value 
selected  from  the  specific  domain  for  an  attribute.  Higher 
normal  forms  must  be  enforced  by  DBA. 

3.  Database  System  Architecture 

DBA  must  also  understand  the  architecture  of  the 
database  system  to  exploit  efficiencies  or  avoid 
deficiencies.  Since  database  users  do  not  have  static 
applications  and  the  data  stored  Is  also  dynamic#  DBA  must 
know  hoe  to  monitor  and  enhance  performance#  If  possible# 
when  user  requirements  can  no  longer  be  satisfied, 
requirements. 
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One  of  the  primary  reasens  for  employing  a  database 
management  system  is  to  snare  the  data  among  users.  This 
provides  a  reduction  in  the  storagg  of  redundant  data  and 
alleviates  the  possibility  of  anomalies  associated  with 
redundancy.  The  concept  of  sharing  data  must  be  temperea 
with  the  requirements  of  user  needs  and  information 
security.  Therefore,  a  means  must  ce  avaiiaoie  to  provide 
control  over  the  data  and  to  permit  the  controlling 
authority  to  decide  who  will  have  access  to  the  data  he 
controls. 

Xn  RDM  1100  the  control  of  data  is  a  function  of 
ownership  and  access  rights.  The  creator  of  an  object  is  the 
owner  of  that  object.  Objects  wnlch  may  be  owned  are 
databases,  relations,  views  and  stored  commands.  The  owner 
of  the  object  must  explicitly  permit  other  users  (less  DBA} 
to  access  the  object  or  portions  of  an  object  (e,g,, 
specific  relation  attribute  values).  For  a  more  detailed 
discussion  of  ownership  and  access  rights,  see  Section  IV  c, 
S.  Recommendations 

In  database  design  the  first  step  is  to  develop  a 
strategy  to  meet  the  organizational  information 
requirements,  since  the  conceptual  schema  is  the 
comprehensive  data  description  of  the  organizational 
information  structure,  the  second  step  would  entail  the 
designing  of  the  conceptual  schema.  By  using  this  approach. 
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data  independence  can  be  maintained  which  will  prevent  the 
modification  of  applications  programs  due  to  changes  In  the 
physical  database.  Further,  the  dependencies  between  the 
conceptual  schema  and  user  requirements  can  be  documented  to 
ensure  changes  at  the  conceptual  level  will  not  result  In 
changes  to  the  applications  programs. 

It  should  be  noted  that  DBA  must  control  the 
creation  of  relations  and  indices  in  such  a  manner  so  that  a 
specific  normal  form  can  be  maintained.  In  addition  to 
conforming  to  the  lirposed-ncriral  form  constraints,  each  user 
creating  relations  to  satisfy  his  own  needs  must  not  violate 
the  relations  of  the  database  supporting  other  users.  Such 
violation  will  certainly  contain  excessive  and  redundant 
information,  and  undermine  the  initial  database  design. 
Additionally,  if  individuals  sharing  a  database  are 
permitted  to  create  objects  at  win,  the  sharing  of  oata  oy 
all  users  may  be  subverted  and  the  database  could  rapidly 
deteriorate  to  a  user-determined  tiling  system. 

C.  THE  DATABASE  DESIGN  •  THE  EXTERNAL  SCHEMA 

As  important  as  the  physical  and  conceptual  schemas  are 
to  the  implementation  of  a  single  database,  the 
establishment  of  the  external  schema  is  critical  to  the 
users.  In  considering  divergent  user  application 
requirements,  the  external  schema  provides  the  means  to 
define  precisely  what  will  satisfy  each  users  information 


needs.  The  external  seneire  ot  the  database  Is  different  for 


each  user  or  group  of  users.  These  schemas  are  composed  ot 
subsets  of  the  conceptual  schema.  The  definition  of  the 
contents  of  a  particular  external  schema  is  normally 
accomplished  through  access  control  of  objects  existing  at 
the  conceptual  level.  By  restricting  the  relations, 
attributes,  stored  commands,  and/or  views  available  to  a 
user,  a  subset  ot  the  entire  database  is  defined. 

A  user's  access  to  the  database  is  determined  by  the 
user's  aceess  rights.  The  access  rights  of  a  user  are 
authorized  by  DBA  and  consequently  DBA  controls  user  aceess 
to  the  database.  In  addition  to  the  verification  and 
matching  of  host  ID  and  host-user  ID  to  the  database 
system-user  ZD,  these  access  rights  are  the  only  means  for 
access  control  in  the  majority  of  database  systems,  in  RGL 
the  permit  and  DENY  commands  on  physical  objects,  virtual 
objects,  and  stored  commands  can  be  used  to  establish  the 
various  external  schemas  of  the  database. 

!•  Permit/Deny  Access 

There  are  two  aceess  rights  whleh  must  be  available 
in  a  database  system  to  provide  a  user  with  the  appropriate 
level  of  information.  These  access  rights  are  read  and 
write.  Execute  privileges  can  be  considered  a  special  case 
of  indirect  reed/vrlte  just  as  ereate  can  be  a  special  case 


of  write 


The  two  commands  in  RQl  which  assign  the  access 
rights  are  PERMIT  and  CENT.  The  permit  command  grants  a 
user  a  specified  access  right  over  an  object  or  commana  and 
the  DENT  command  revokes  or  removes  such  access  rights. 
DENY  is  primarily  employed  to  revoke  a  previously  grantee 
PERMIT. 

The  aceess  rights  available  in  RQL  are  READ,  write. 
EXECUTE,  and  CREATE.  PERMIT  READ  provides  access  to  the 
specified  objects  (relation,  view  or  named  attributes  of  a 
relation  or  view).  To  modify  or  add  data  to  existing 
relations  in  the  database  a  PERMIT  write  for  the  user  or 
group  of  users  on  the  objects  or  portions  of  objects  must  be 
explicitly  authorized.  The  keyword  ALL  can  be  used  to  grant 
read,  write,  and  execute  privileges  to  a  user  or  group  of 
users.  Only  the  owner  of  the  object  is  authorized  to  DENY 
access  to  the  object. 

There  are  two  cases  of  implicit  access  in  rdm  1100, 
DBA  is  authorized  access  to  all  objects  in  the  database  to 
which  he  has  not  been  explicitly  denied  aceess  by  the  owner. 
Even  if  access  is  denied  to  DBA  by  the  owner,  DBA  may  still 
destroy  the  object  by  deleting  all  references  to  it  in  the 
database  relations  (non-user>.  Additionally,  the  owner  of 
any  objeet  is  permitted  aceess  to  that  ooject.  All  other 
accesses  must  be  authorized  by  the  owner  of  the  object. 
This  is  the  essence  of  the  aceess  control  system. 
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The  database  management  system  must  provide 
facilities  to  create  physical  objects  In  tne  database. 
Initially,  tne  database  must  be  created  with  an  assigned 
DBA.  Following  this,  the  physical  objects  in  tne  database 
must  be  erected.  Although  an  index  is  not  a  pnyslcal  object 
which  may  be  manipulated  by  the  user,  it  is  discussed  in 
this  topic. 

In  RQl  the  right  to  execute  the  CREATE  database 
command  must  be  explicitly  granted  by  the  system  DBA.  once 
a  usar  has  authorization  to  create  a  database,  tne  execution 
of  the  CREATE  DATABASE  command  maxes  him  DBA  of  the  named 
database.  To  add  new  users  to  the  database,  DBA  employs  the 
database  administrator  utilities  ibbau)  program.  The  dbau 
new. users  command  assigns  the  host-user  ZD  and  host  ID  and 
places  them  In  the  HOST. USERS  relation.  The  DESTROY 
DATABASE  command  ean  only  be  executed  by  DBA,  (l.e,,  tne 
owner  of  the  database], 

CREATE  <objects>  is  else  controlled  through  the 
PERMIT  and  CENT  commands.  The  permission  is  similar  to 
CREATE  DATABASE  in  that  only  DBA  for  a  particular  database 
may  authorize  the  creation  of  objects.  Relations  and 
Indices  are  the  physical  objects  which  a  user  may  be 
authorized  to  create.  Only  the  owner  of  a  relation  is 
allowed  to  create  an  index  on  the  relation  using  the  create 
INOEX  command.  However,  the  DBA  must  authorize  the  owner 


us«  of  the  CREATE  INDEX  coirirand.  Each  of  the  above 
discussed  commands  has  a  counterpart  for  revocation,  only 
the  owner  or  DBA  say  destroy  relations  and  indices. 

3.  Create  Virtual  Cblects 

Gnce  the  physical  objects  are  created.  It  Is 
necessary  to  create  the  virtual  objects  In  the  conceptual 
scheme  wnleh  will  define  the  external  schema  for  each  user. 
Views  are  tne  virtual  objects  which  a  user  may  be  authorized 
to  create. 

CREATE  VIEW  requires  the  user  to  nave  access  to  the 
relations  over  which  the  view  is  defined.  Only  the  owner  of 
the  view  may  destroy  the  view  with  the  DESTROY  <object> 
command. 

4.  Access  Via  Stored  Commands 

Finally,  an  Indirect  rcad/wrlte  (execute)  access  is 
necessary  to  allow  users  to  extract  Information  from  the 
database  through  the  use  of  stored  commands.  Stored  command 
is  an  RGL  term  for  a  user  defined  function  or  procedure. 
Although  this  feature  may  net  be  available  In  every  database 
system,  it  Is  very  useful  end  powerful  when  provided.  In 
addition  to  the  efficiency  Issue  of  stored  commands 
discussed  previously.  It  Is  muen  easier  tor  the  user  to 
execute  stored  commands  than  to  input  long  queries,  m  RQL 
PERMIT  EXECUTE  allows  a  specified  user  or  group  of  users  to 


execute  stored  commands. 


5. 


Thera  ere  three  methods  for  providing  an  external 
schema  to  a  user  or  group  ef  users.  The  first  method  is 
through  restriction  of  aecess  or  the  physical  objects  in  the 
database.  The  second  method  is  to  define  virtual  relations 
which  consist  only  of  the  necessary  subset  of  data  the  user 
is  required  to  access.  Finally,  the  third  method  entails 
the  extraction  of  information  from  the  database  through  the 
exclusive  use  of  stored  commands. 

In  RQL  the  major  problems  with  the  first  two  methods 
are  the  addition  and  deletion  of  data  and  implementation  of 
ALL,  As  mentioned  in  Section  III  there  are  too  many 
restrictions  on  the  use  of  views  tor  updating  database. 
Additional  problems  can  arise  using  the  first  method  as  a 
result  of  the  system  assigning  default  values  to  attributes 

X 

which  are  not  explicitly  listed  in  an  APPEND  command.  For 
example,  an  insertion  of  a  tuple  with  a  blank  key  field 
(employee  number)  tor  a  new  employee's  salary  and  name  would 
result  in  a  tuple  containing  the  employee's  name  and  salary 
with  a  blank  key  field,  A  separate  insertion  containing  the 
employee  number  and  name  would  result  in  two  tuples  in  the 
same  relation  for  a  single  employee. 

The  stored  command  can  be  executed  without  granting 
the  user  aecess  rights  to  the  relatlon(s)  which  are  accessed 
by  the  command.  However,  exclusive  use  of  stored  commands 
for  information  retrieval  is  not  reasonable  since 
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anticipation  of  every  query  which  a  user  could  possitly 
require  is  not  possible. 

There  Is  a  trade-off  between  access  control, 
performance,  and  relational  perspective.  Each  of  these 
Issues  requires  the  sacrifice  of  one  of  tne  trade-off 
features.  in  order  to  resolve  this  problem,  a  combination 
of  the  prescribed  methods  Is  required.  The  use  of  stored 
eommandq  to  input  and  delete  data  In  a  well  structured 
database  removes  tne  restrictions  on  tne  use  of  views. 
Further.  stored  commands  can  force  the  entry  of  all 
mandatory  attribute  values  for  a  tuple  through  parameter- 
argument  matching  which  eliminates  the  duplicate  tuple 
problem  described  above.  Combining  stored  commands  for 
updatlnq  with  the  use  of  views  to  define  tne  external 
schemas  would  provide  the  most  logical  approach,  in  order 
to  employ  this  strategy  a  major  system  change  is  reoulred  in 
the  implementation  of  ALL. 

First.  It  should  be  obvious  that  the  most  logical 
mechanism  for  producing  an  external  schema  is  the  view. 
However,  the  major  problem  is  the  necessity  to  provide 
access  to  the  ATTRIBUTE  relation  to  permit  tne  use  of  ALL 
with  the  view  name.  Therefore.  ALL  should  be  implemented 
such  that  only  the  attributes  or  relations  the  users  are 
authorized  to  aecess  are  returned.  Tnls  should  not  carry  an 
implicit  access  to  tne  ATTRIBUTE  relation.  Access  to  the 
ATTRIBUTE  relation  ean  be  restricted  by  implicit  use  of 


user-id  predicates  on  all  queries  on  data  dictionary 
relations.  The  performance  issue  results  from  the 
implementation  of  ALL  in  the  host  and  the  resultant 
communications  between  the  host  and  the  backend  to  process  a 
query  containing  ALL.  This  performance  degradation  can  be 
rectified  by  implementing  ALL  in  the  backend  relational 
database  machine. 

D.  SYSTEm  SERVICES 

The  third  area  is  the  services  provided  to  DBA  by  the 
system.  DBA  will  use  these  services  to  facilitate  system 
backup,  crash  recovery  and  provide  information  about  the 
database.  The  system  services  establish  a  nucleus  of 
Information  and  facilities  which  DBA  may  be  required  to 
augment  for  his  own  personal  preferences  and  needs. 

1.  System  Backup 

Two  areas  of  system  backup  must  be  provided  to  DBA 
to  ensure  proper  system  functioning.  The  first  area  is  the 
necessity  of  providing  a  means  to  record  the  contents  of  the 
detabase  when  it  is  in  a  consistent  state.  This  is  employed 
most  frequently  by  the  system  DBA  and  is  addressed  further 
in  the  next  tople  on  crash  recovery. 

The  second  area  is  the  need  to  return  the  database 
to  a  previous  consistent  state  as  a  result  of  aborting  a 
transaction.  A  transaction  is  a  single  command  or  a  series 
of  commands  which  must  be  left  uncommltteo  until  the  final 
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command  has  finished.  This  situation  ean  result  froir  a  user 
decision  to  abort  his  transactlen  prior  to  completion  or  the 
naeasslty  of  rolling  a  transaction  back  as  a  result  et 
deadlock.  Deadlock  occurs  in  a  multiple  user  system  when 
one  user  holds  a  resource  (e.g.,  relations)  another  user 
requires  and  the  second  user  holds  a  resource  tne  first 
requires.  In  this  situation,  the  system  is  said  to  be 
deadlocked  since  neither  user  ean  complete  his  transaction. 
To  resolve  deadlock  only  one  of  the  transactions  must  be 
rolled  back.  The  solution  to  user  aborts  is  to  restore  the 
database  to  the  state  it  was  in  prior  to  the  abort. 

In  RDM  1100  the  function  of  backing  up  transactions 
is  Invisible  to  DBA.  The  TRANSACT  relation  (to  be  discussed 
later)  is  used  to  maintain  the  before  and  after  attribute 
values  affected  by  the  transaction  for  relations  created 
with  the  logging  option.  The  BATCH  relation  is  used  for  the 
other  relations.  A  transaction  is  by  default  a  single 
command  unless  the  explicit  commands  begin  before  and  end 
TRANSACTION  after  a  group  of  commands  is  specified,  abcrt 
TRANSACTION  can  then  be  Issued  after  BEGIN  and  before  end  to 
cause  rollback.  RDM  iiOO  employs  an  optimistic  concurrency 
control  algorithm  which  does  not  prevent  deadlock  from 
occurring.  The  resolution  of  deaalock  is  completely 
invisible  to  the  user  and  DBA, 
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Crain  Recovery 

Anotner  facility  which  irust  be  provided  to  DBA  is 
the  ability  to  recover  freir  a  system  malfunction,  mis  Is 
particularly  Important  when  the  data  on  the  disk  has  been 
lost  or  contaminated.  To  avoid  excessive  time  delays, 
periodic  copies  of  the  entire  database  must  oe  made  to 
reduce  the  amount  of  updating.  The  frequency  of  copying  the 
database  Is  dictated  by  the  number  of  enanges  In  a  period  of 
time  and  the  time  demands  of  the  applications  programs.  The 
normal  method  of  recovery  requires  the  most  recent  copy  of 
the  database  and  the  transactions  whicn  have  occurred  since 
the  copy  mas  made.  Once  the  copy  of  the  database  is  loaded, 
the  transactions  are  rerun  to  bring  the  database  up  to  date. 
Since  the  chronological  list  of  transactions  Is  the  key  to 
recovery.  It  must  be  copied  from  the  database  on  a  frequent 
basis  even  though  the  copying  of  the  entire  database  may  be 
less  frequent  due  to  the  time  required.  Of  course,  some 
transaction  which  were  in  progress  or  not  in  a  transaction 
list  must  be  reinitiated  by  the  user. 

ROM  1100  provides  DUMF  DATABASE  and  LOAD  DATABASE 
commands  In  the  DEAU  facility.  Additionally,  dump 
TRANSACTION  is  provided  co  make  copies  of  the  transaction 
log.  The  command  which  allows  rerunninq  transactions  after 
a  LOAD  DATABASE  command  has  been  executed  is  ROLLFORWARD. 


The  database  system  employed  must  provide  a  data 
dictionary  and  statistical  information  on  the  database 
configuration  and  performance,  A  data  dictionary  contains 
descriptive  information  about  the  database.  It  must  include 
all  the  various  schemas  (physical,  conceptual,  external)  and 
should  include  cress-reference  information  such  as  which 
programs  use  what  data  and  synonyms. 

In  RDM  1100  there  are  13  system-supplied  database 
relations  which  contain  descriptive  information  about  the 
associated  database.  In  addition,  there  are  seven  system 
relations  which  provide  a  global  description  of  the  database 
machine. 

The  system  relations  provide  a  cataloq  of  the 
databases  in  RDM  1100,  a  list  ef  disics  known  to  the  system, 
status  and  types  of  locks  in  the  system  (used  for  concurrent 
processing),  and  the  configuration  of  the  communications 
Interface  to  the  attached  host(s).  Another  system  relation 
provides  information  concerning  the  activity  currently 
taking  place  in  the  database.  Two  additional  relations  are 
used  to  provide  performance  data. 

Perhaps  more  Important  for  OBa  are  the  13  relations 
associated  with  eaeh  database.  Each  relation  is  listed 
below  and  a  brief  description  of  tne  type  of  information 
contained  is  provided.  The  first  11  are  used  to  supply  data 
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dictionary  information  and  the  last  two  provide  information 
related  to  transaction  management. 


RELATION 


A  single  tuple  is  provided  for  each 
object  in  the  database.  This  tuple 
includes,  as  appropriate,  the  name  of 
the  object,  owner,  relation  identi¬ 
fication  number,  size,  location, 
number  of  tuples  and  their  length, 
type  of  object  (user,  system,  trans¬ 
action  log.  file,  view  or  stored 
command),  and  the  number  of 
attributes. 


$ 
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ATTRIBUTE 


INDICES 


A  tuple  is  entered  for  every  attribute 
in  the  database.  This  tuple  Includes 
the  attribute  identification  number, 
data  type,  maximum  length,  associated 
relation  IC.  and  attribute  name. 


Each  index  has  a  tuple  in  the  rela¬ 
tion.  Ihe  attributes  include  the 
index  identification  number,  relation 
ID.  number  of  attributes  in  the  index, 
location,  and  attrioute  ID(s). 


PROTECT 

QUERY 

CRQSSREF 


USERS 

HOST.USERS 

BLCCKALLOC 

DISK. USAGE 

DESCRIPTIONS 


Contains  information  associated  witn 
the  explicit  access  authorized  on  objects 
lor  users  In  tne  database. 

Contains  the  stored  commands  and 
views. 

Describes  the  dependencies  among 
relations,  indices  and  stored 
commands  in  the  dataoase.  The  depend¬ 
encies  are  system  defined  and  not  user 
specified. 

Describes  the  mappings  between  user 
identification  numbers,  names,  and 
user  groups. 

Defines  the  mapping  between  the  nost 
ID.  host-user  ID.  and  rdm  1100  user  ID, 

Catalogs  the  sector  assignment  within 
a  zone.  Each  tuple  represents  a  sector 
and  the  assigned  ooject. 

Describes  database  disk  allocation. 

Contains  user-specified,  textual 
descriptions  of  objects  and  attributes 
in  the  database. 
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BATCH 


Contains  temporary  logging  inforiraticn 
used  by  the  system  for  transaction 
management*  This  relation  provides 
Information  on  transactions  against 
logged  and  ncn-iogged  relations  so 
they  can  be  canceled  if  regulred. 

The  transaction  information  is  held 
until  tne  transaction  is  committed. 

TRANSACT  Permanent  logging  information  used 

for  erash  recovery* 

All  of  the  above  relations  provide  tne  comprenenslve 
picture  of  the  database*  Although  the  information  is  in  the 
relations,  much  of  it  is  ret  in  a  usable  format*  For 
example,  only  the  RELATION  relation  contains  the  textual 

name  of  a  relation*  Other  relations  use  the  Internally 
assigned  relation  ID*  Further,  some  of  the  information  is 
encoded*  In  order  to  translate  this  information  into  an 
understandable  format  DBA  must  develop  stored  commands 
(preferable  to  ad  hoc  queries)*  The  number  of  stored 
commands  will  be  dependent  on  the  desires  of  DBA*  However, 
a  minimum  subset  should  include  commands  to  list  the 
relations,  attributes,  lndlees,  attributes  in  an  index, 
access  list  associated  with  an  object,  description  of  an 
object,  and  dependencies. 


The  follo«lng  stored  commands  are  used  to  yield  the 
minimum  subset*  TABLES  is  used  to  provide  a  list  of  objects 
by  type  (DBA-supplied  parameter  to  TABLES).  For  relations* 
relation  name*  type*  and  the  number  of  attributes  and  tuples 
in  the  relation  are  provided.  FIELDS  provides  the  relation 
name  (parameter  specified  by  DBA  to  FIELDS)*  attribute  name* 
data  type  of  the  attribute  (bin*  char*  lnt*  etc.)*  and  the 
length  of  the  attribute  tor  every  attribute  in  the  relation. 
ALL.INDICES  provides  a  list  of  all  indices  on  user  relations 
in  the  database.  The  information  provided  includes  the 
relation  name*  index  identification  number*  number  of 
attributes  in  the  index*  and  a  narrative  description  of  the 
type  of  index.  An  additional  command*  INDEX.LIST*  is  used 
to  .  provide  the  same  information  as  all.Indices  except  a 
relation/view  name  is  passed  as  a  parameter  and  only  the 
indices  on  that  relatlon/viev  are  returned,  att.in.incxi 
and  ATT.IN.INDX2  are  used  to  list  the  attributes  in  an  index 
by  name.  These  commands  require  two  parameters;  the  index 
ID  and  the  relation  name.  The  reason  for  the  development  of 
two  separate  commands  is  the  readaolllty  of  the  output. 
PROTECTION  provides  the  object  name*  user  name*  and  type  of 
access  authorized  for  an  object  which  Is  passed  as  a 
parameter.  Another  command*  ACCESS. LIST,  is  provided  to 
describe  an  object  and  the  associated  access  list  tor  a 
particular  object,  whatis  provides  a  narrative  explanation 
of  its  parameter  from  the  DESCRIPTION  relation,  depends  Is 


used  to  provide  a  list  of  the  dependencies  on  an  object. 
Finally,  another  useful  command  is  ahQCREATES  which  provides 
a  list  of  users  who  have  been  granted  create  permission  in 
the  database.  RQL  constructs  for  the  stored  commands 
described  above  are  provided  in  Appendix  a. 

4.  Translator 

Upon  Implementation  of  a  relational  database,  It 
will  be  necessary  to  load  the  data  into  the  system.  Since 
the  data  exists  on  some  storage  device  (disk,  tape,  etc,), 
there  should  be  a  mechanism  for  presenting  the  data  to  the 
system  for  Immediate  loading  in  a  relational  format. 

In  ROW  1100,  assuming  the  data  can  be  collated  as  a 
sequence  of  records  on  a  disk  er  tape,  the  'translator”  can 
then  be  used  to  load  the  database  on  a  reiation-by-relatlon 
basis.  The  'translator'  will  ask  a  series  of  questions  to 
ascertain  the  incoming  data  format  and  establish  the 
relation  schema.  The  following  questions  must  be  answered 
for  a  relation.  The  answers  are  parenthesized, 

1,  Output  directly  to  the  ROM?  (y/n) 

2,  Input  file  (name) 

3,  Database  (name) 

4,  Name  of  table  (relation  name) 

5,  Name  of  1st  field  (name  of  first  attribute) 

6,  Enter  input  type  and  length  (input  tile  format) 

7,  Enter  output  type  and  length  (cl2,  11,  etc,) 
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8,  Starting  position  (input  file) 

(Questions  5  through  8  are  repeated  for  each 

attribute.) 

9.  Record  length  (input  file) 

E,  USER  SERVICES 

The  fourth  area  is  DBA  support  provided  to  the  users  of 
the  relation  database  systeir.  DBA  should  provide 
servlees/facllltles  to  the  users  of  the  database  depending 
on  their  applications  and  experience  level,  a  discussion  of 
user  services  in  two  general  areas  will  be  addressed.  These 
areas  are  providing  a  help  facility  and  providing  stored 
commands. 

1«  Help  facility 

As  with  any  interactive  system,  a  help  facility  is 
required  to  preclude  time-consuming,  trial-and-error 
corrective  procedures.  For  a  relational  database  system  the 
help  facility  should  include,  at  a  minimum,  the  syntax  and 
explanation  of  every  language  command  and  an  explanation  of 
the  stored  commands,  relations,  and  views. 

In  RQL  this  can  be  accomplished  by  creating  a  help 
relation  with  three  attributes  (object,  line  number,  ana 
text)  end  defining  e  stored  command  which  given  an  object  as 
a  parameter  will  explain  its  purpose  or  use.  The  stored 
command  must  contain  appropriate  preoicates  in  tne  where 
clause  to  ensure  the  user  can  only  retrieve  information  from 
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the  help  relation  about  objects  which  he  is  authorized 
access.  An  example  of  the  help  relation  and  stored  command 


is  provided  in  Appendix  A. 

2.  Stored  Commands  Provided  fcv  DBA 

DBA  must  have  an  in-depth  knowledqe  of  the  query 
language.  It  is  not  reasonable  to  assume  that  the  average 
user  will  become  proficient  in  tne  use  of  the  query 
language.  Both  query  language  complexity  and  performance 
issues  must  be  considered.  The  examples  in  Sections  111  and 
V  demonstrate  some  of  the  complexities  in  RQL,  DBA  will  ce 
required  to  assist  the  user  in  the  proper  formulation  of 
some  queries.  in  addition,  the  users  will  look  for 
assistance  when  confronted  with  any  perceived  problem  in  the 
database.  Since  DBA  is  a  database  expert,  the  user  will 
naturally  requast  his  assistance. 

in  addition  to  applications  oriented  RQL  stored 
commands,  which  are  not  dlseussed.  DBA  should  provide 
commands  similar  to  those  described  earlier  in  this  section 
for  the  user.  Specifically,  depends,  whatis,  protection, 
ATT.IN.INDX1,  ATT.1N.XNDX2.  1N0EX.HST,  FIELDS.  TABLES.  and 
HELP  should  be  provided.  The  only  difference  between  the 
DBA  commands  and  the  user's  stored  commands  is  the  inclusion 
of  the  necessary  predicates  in  the  where  clause  to  limit  the 
response  to  data  whleh  the  user  has  been  granted  access. 
Other  minor  modifications  may  also  be  desired.  For  example. 
TABLES  could  be  parameter less  and  return  all  relations. 


views,  and  stored  commands  to  which  the  user  has  access. 
PROTECTION  eould  be  modified  to  return  only  the  accesses  on 
objects  the  user  owns. 

F.  SECURITY 

The  fifth  area  for  DBA  concern  is  the  security  of  the 
database.  The  security  of  a  database  system  is  plagued  with 
the  same  problems  associated  with  computer  security  In 
general.  The  normal  mechanism  tor  security  is  access 
control.  Since  a  database  system  is  attached  (backend)  to  a 
host,  the  security  measures  provided  by  the  host  are  the 
first  level  of  security  afforded  the  database  system.  The 
user  ID-password  logon  procedure  employed  by  generai-puroose 
computers  can  be  used  for  database  systems  to  provide  the 
same  security  checks.  Additionally,  a  host  ID  check  in 
conjunction  with  the  previously  mentioned  validation  can  be 
performed  when  a  backend  system  is  used.  Security  Is  also 
afforded  by  the  backend  machine  configuration  since  the 
database  machine  is  separate  from  the  host  and  uses  Its  own 
disks  for  data  storage. 

The  first  security  check  performed  by  RDM  1100  is  the 
verlflcetlon  of  the  host  and  host-user  ID.  These  IDs  are 
verified  each  time  a  request  is  made  from  tne  host  to  the 
backend  machine.  Since  the  security  of  the  database  is 
closely  associated  with  the  security  of  the  host,  the  use  of 
passwords  on  the  host  for  Identification  and  verification  is 
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essential.  The  user  iD-passwerd  logon  procedure  is  not 
employed  In  RDM  1100  but  is  taken  from  the  nost  which  means 
there  is  not  an  additional  10-password  required  for  the 
baekend  machine.  in  addition  to  the  verification  and 
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access  control 

rights 

are 

the  only 

security  mechanises  available  in  RDM  1100. 

There  are  two  Implicit  aeeess  rights  In  ROM  1100.  the 
owner  (creator)  of  any  objeet  and  DBA  are  permitted  access 
to  that  object  unless  explicitly  denied  by  the  owner.  All 
other  aeeesses  must  be  authorized  by  the  owner  of  the 
object.  This  Is  the  essence  of  the  security  system.  The 
remainder  of  this  tople  will  discuss  specific  security 
weaknesses  In  the  RDM  1100. 

1.  Security  Aspects  of  *ALL ' 

A  crucial  aspect  for  security  Is  the  implementation 
of  ALL.  ALL  Is  used  In  a  query  as  a  synonym  for  every 
attribute  of  the  relation  In  the  target  list.  As  previously 
discussed,  there  Is  not  a  user  ID  qualification  associated 
with  ALL.  Therefore,  the  translation  of  ALL  to  its 
attribute  equivalents  Is  based  on  tne  objeet  (relation  or 
view).  ALL  does  not  work  with  a  view  or  a  relation  unless 
the  user  has  READ  aeeess  on  the  ATTRIBUTE  relation. 
However,  once  this  access  Is  authorized,  the  user  can 
examine  the  entire  conceptual  schema  which  is  certainly  a 
violation  of  security. 


61 


2.  System  Messages 

The  use  of  relation. attrlbute(s)  or 

vlew.attrlbute(s)  in  the  target  list  returns  two  separate 
error  messages  if  read  access  to  the  object  is  rot 
permitted.  Cne  error  message  (permission  denied  on  ,..) 
indicates  the  attribute  name  is  valid  but  access  is  not 
authorized.  The  other  error  message  (...  not  found)  can  be 
interpreted  as  the  attribute  name  is  non-existent.  Aithougn 
extremely  tedious,  the  error  messages  can  be  used  in  a 
trall-and-error  method  to  obtain  the  conceptual  schema. 

3.  User  Identification  Numbers 

Another  serious  weakness  in  the  security  of  rql  is 
the  deletion  of  a  user  from  a  database.  The  easiest  method 
is  to  delete  the  user  from  the  HQST.USERS  relation  which 
will  prohibit  him  from  opening  the  database.  However,  if  a 
new  user  is  added  to  the  database  from  DBAU  and  the  system 
assigns  his  the  UID  which  was  previously  assigned  to  a 
deleted  user,  the  new  user  win  inherit  all  the  accesses 
which  were  established  by  DBA  and  owners  for  that  uid.  This 
is  not  acceptable  since  there  should  not  be  any  implicit 

i 

authorizations  for  a  new  user. 

4.  Recommendations 

The  recommendations  for  correcting  the 
Implementation  of  ALL  are  dlseussed  in  Section  IV  C5  above. 
Although  not  as  informative,  the  return  of  a  single  error 
massage  tor  both  access  denied  and  relation. attribute  not 
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found  would  provide  less  Information  about  the  conceptual 
sehema  of  the  database.  From  a  user's  perspective  it  does 
not  appear  to  be  significant  whether  access  is  denied  or  the 
object  is  not  in  the  database.  The  critical  issue  is  to 
avoid  dlvulgence  of  the  conceptual  schema  to  a  user  not 
authorized  this  information. 

The  two  methods  for  correcting  the  user  ID  problem 
are  the  explicit  deletion  of  all  aecess  rights  in  the 
database  (PROTECT,  USERS,  HCST„USERS)  for  the  old  user  by 
DBA,  or  providing  a  command  in  the  dbau  to  delete  a  user 
from  a  specified  database  whleh  will  explicitly  remove  all 
the  accesses  the  user  has  been  granted.  The  second  metnod  is 
preferable  to  the  first  since  the  system  should  provide  this 
service  to  DBA, 

G.  FINE-TUNING  PERFORMANCE 

The  last  area  of  concern  for  DBA  is  the  performance 
enhancement  of  an  existing  database.  Given  that  a 
relational  database  system  has  already  been  selected  and  the 
overall  performance  factors  have  been  established,  DBA 
nevertheless  does  have  a  few  tools  at  his  disposal  which  can 
enhance  performance.  There  are  features  in  the  query 
language  implementation  whleh  are  more  efficient  than 
others.  For  example,  a  join  can  run  faster  depending  on 
which  relation  is  held  in  cache.  One  language  uses  the  last 
relation  listed  in  the  query  if  other  factors  are  equal, 
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Thus#  the  order  of  the  reletions  could  be  important. 
Another  example  is  the  use  of  parenthesis  to  resolve 
ambiguity  In  a  list  of  logical  predicates.  These  features 
are  highly  Implementation-dependent  and  will  not  be 
addressed  further.  The  ether  three  features  are  data 
reorganization#  indices#  and  data  placement. 

In  RQL  DBA  will  be  reoulred  to  develop  a  performance 
monitoring  strategy  which  may  include  the  periodic  execution 
of  stored  commands  specifically  designed  to  collect 
performance  data. 

1.  Data  Reorganization 

As  data  is  added  to  and  deleted  from  the  database# 
there  is  an  associated  fragmentation  of  relations  in 
physical  storage.  Even  though  many  database  systems  provide 
the  capability  to  reserve  extra  space  for  relations#  this 
will  result  only  In  a  delay  of  fragmentation.  The  extent  of 
fragmentation  must  be  monitored  and  fragmentation  eliminated 
when  necessary. 

DBA  may  specify  the  number  of  blocks  for  a  database 
end  for  a  relation  In  RQL.  Additionally#  FlLLFACTORs  can  be 
specified  for  clustered  Indices  on  relations.  This 
FXLLFACTQR  determines  the  percentage  of  each  disk  block 
which  will  be  used  for  the  data  In  the  relation  when  a 
clustered  Index  is  created,  when  the  fragmentation  becomes 
excessive#  the  clustered  index  can  be  destroyed#  recreated# 
and  a  new  FXLLFACTQR  assigned.  This  procedure  will  resort 
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the  data  in  the  blocks  available  for  the  relation.  A 
relation  will  be  allowed  to  crow  until  it  uses  all  the 
blocks  It  is  authorized  or  all  blocks  in  the  database  are 
full*  Since  blocks  are  not  re-used  when  data  is  deleted 
fro*  a  relation*  this  will  result  in  reaening  maximum  block 
capacity  and  fragmentation.  DBA  can  monitor  this  activity 
by  writing  a  stored  command  on  the  BLGCfcS  relation.  The 
ability  to  eliminate  fragmentation  for  a  non-indexea 
relation  will  depend  on  the  number  of  free  consecutive 
blocks  available  in  the  database*  If  enough  blocks  are 


available 

*  the  data 

can 

be 

retrieved 

into 

a 

temporary 

relation 

defined 

over 

the 

empty  blocks* 

tne 

original 

relation 

destroyed. 

and 

the 

temporary 

relation 

renamed* 

This  strategy  can  also  ba  employed  when  reclustering  does 
not  offer  a  satisfactory  solution  to  fragmentation. 

2*  Indices 

Indices  can  enhance  the  performance  of  a  database 
for  data  retrieval,  (Ref.  2]  and  (Ref*  31  have  documented 
the  actual  enhancement  In  RDM  1100.  since  indices  are 
appileatlon-orlented*  they  are  highly  desirable  for 
databases  where  the  majority  ef  operations  are  retrieval  of 
data  over  large  relations  or  relations  wnlch  are  fairly 
static  ean  be  Identified*  If  numerous  update  and  apoend 
transactions  are  envisioned*  then  a  degradation  in 
performance  could  result  due  to  the  constant  updating  of  the 
Indices*  Therefore*  OBA  should  be  aware  of  the  size  of  the 
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relations  and  types  of  operations  performed  on  the 
relations.  For  example,  if  Insertion  is  prevalent  then 
avoidance  of  indices  on  the  relations  which  require  numerous 
APPENDS,  if  possible,  may  reduce  degradation. 

3.  Data  Placement 

Hypothetically,  the  placement  of  data  on  disks  can 
enhance  performance.  For  example,  if  a  join  between  two 
relations  is  performed  frequently,  then  placing  the 
relations  on  separate  disks  will  reduce  disk  head  movement 
as  data  is  moved  into  cache.  Although  this  hypothesis  has 
not  been  verified  due  to  the  lack  of  facilities  for  placing 
data  in  ROL,  the  data  placement  strategy  should  be 
considered  when  explicit  assignment  of  physical  storage  is 
available.  This  could  be  even  more  significant  when 
processing  data  on-the-fly  is  realized,  considering  the 
speed  discrepancy  between  reading  data  and  moving  disk 


heads. 


* 

i 

i 

i 

j  V.  EVALUATION  OF  THE  RELATIONAL  SYSTEM 

A*  THE  FULLY  RELATIONAL  SYSTEM 

1 .  The  Fully  Relational  Characteristics 

The  definition  of  e  "fully  relational"  database 
management  system  is  given  ty  Chris  Date  [Ref.  7].  Date 
suggests  that  most  existing  systems  are  not  fully 

I 

relational.  The  primary  benefit  of  considering  fully 

i 

relational  as  a  standard  and  goal  for  implementation  is  in 
the  algebraic  power  of  the  language  and  tne  consistency  of 
system  supplied  functions.  If  the  system  is  deficient  in 
any  characteristics  which  Cate  describes,  appropriate  action 
*  may  be  taken  to  provide  a  semblance  of  a  fully  relational 

system.  First,  the  concept  of  fully  relational  is  defined; 
then  a  comparison  of  RDM  1100  and  RUL  to  the  definition  is 
addressed. 

In  order  for  a  database  to  be  characterized  as  fully 
relational  it  must  support  tne  following: 

a,  "relational  databases  (including  the  concepts  of 
domain  and  key  and  the  two  integrity  rules);" 

b,  "a  language  that  is  as  powerful  as  the  relational 


algebra 

(and 

that 

would 

remain  so  even 

if 

all 

facilities 

for 

loops 

and 

recursion  were 

to 

be 

deleted)," 

(Ref, 

7) 
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A  relational  database  exhibits  the  following 

properties! 

a.  Relations  are  in  first  norrrai  form, 

b.  Associations  between  relations  are  explicitly 

connected  through  common  attributes. 

e.  Every  value  appearing  in  a  given  attribute  is  taken 
from  the  domain  for  that  attribute, 

d.  Every  relation  has  a  unique  primary  key  which 
distinguishes  (identifies)  individual  tuples. 

In  addition  to  the  above  properties#  two  integrity 
rules  are  required.  First#  a  null  value  is  not  permissible 
as  an  attribute  value  of  a  primary  key,  second#  if  a 
relation  A  has  an  attribute  value  which  is  also  the  primary 
key  of  another  relation  8#  then  at  all  times  tne  attribute 
values  in  relation  A  must  exist  in  a.  This  rule  prevents  the 
missing  linkages  among  relations  when  attribute  values  are 
added  to  relation  A  or  removed  from  relation  B, 

2,  Four  Areas  of  Deficiency 

There  are  four  areas  in  which  RDM  1100  does  not  meet 
the  requirements  for  a  fully  relational  system.  First# 
although  specification  of  the  schema  includes  data  types  for 
each  attribute#  no  notion  of  an  underlying  domain  Is 
Incorporated,  Slnee  attributes  are  defined  by  general 
length  and  type  comparisons  of  attributes  are  limited  only 
to  similar  types  (e.g.#  character  with  character)# 
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meaningless  comparisons  are  allowed,  without  the  concepts  of 
sets,  enumerated  types,  and  ranges  available  in  higher  order 
languages  such  as  PASCAL  or  ACA,  the  support  of  domains  will 
always  Pa  questionable. 

Second,  the  requirement  for  a  unique  primary  Key  Is 
not  enforced.  The  uniqueness  of  an  attribute  value  can  be 
enforced  by  declaring  a  unique  Index  on  one  of  the  candidate 
Kays,  However,  this  associates  an  access  path  with  the 
concept  of  a  key.  These  are  two  logically  separate  Issues 
and  as  such  should  be  dealt  with  separately,  since  the 
existence  of  a  candidate  key  does  not  imply  the  need  for  an 
access  path  on  that  attribute. 

Third,  nulls  are  not  implemented  in  RDM  1100. 
However,  the  default  values  for  Integers  (zero)  and 
characters  (blanks)  are  provided  for  unspecified  attribute 
values,  Tuple(s)  may  be  entered  into  a  relation  without 
values  for  the  key  fields.  Even  If  unique  attribute  values 
are  enforced  through  Index  specification,  at  least  one  tuple 
with  the  default  value  In  the  key  attribute  win  be 
accepted. 


Finally,  relations  are  normally  connected  through 
the  repetition  of  some  (or  all)  of  the  key  attribute  values 
In  one  relation  A  and  in  another  relation  b.  However,  there 
is  no  mechanism  to  ensure  relation  B  does  not  contain  a 
value  In  the  connecting  attribute  which  does  not  exist  in 
relation  A, 
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The  Relational  Completeness 

RDM  1100  performs  all  the  relational  algebra 
operations  defined  In  Section  XIX  with  one  exception.  This 
exception  deals  with  the  elimination  of  duplicate  tuples  in 
the  results  after  applying  certain  operators  (projection, 
division,  natural  join,  etc*).  For  example,  although  the 
result  relation  may  appear  to  satisfy  a  natural  join.  It  is 
obvious  that  duplicates  are  not  a  priori  eliminated,  since 
the  elimination  Is  a  function  of  the  associated  projection. 
Additionally,  a  projection  of  an  attribute  in  a  relation 
with  duplicate  entries  will  return  all  the  values  in  the 
attribute  without  regard  to  duplicates.  A  join  could  be 
simulated  by  forming  a  Cartesian  product  of  the  two 
relations,  applying  the  predicates  to  the  product, 
extracting  the  concatenated  tuples  which  satisfy  the 
predicates,  and  projecting  the  attributes  from  the  target 
list. 

B.  COMPARISON  OF  TWO  QUERY  LANGUAGES 

This  topic  provides  a  comparison  of  RCL  and  SQL.  The 
selection  of  SQL  as  the  comparative  language  is  based  on  the 
relative  familiarity  of  a  large  number  of  people  with  the 
language  and  its  widespread  use. 

1.  -Egual  Power 

The  power  of  the  two  query  languages  is  practically 
Identical.  Both  languages  are  relationaiiy  complete  which 
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implies! 

a,  Any  relation  derivable  iron  the  database  relations 
using  an  expression  in  the  relational  algebra  can  be 
retrieved  using  the  language,  and 

b,  Any  derivable  relation  can  ee  retrieved  using  a 
single  statement  in  the  language, 

2.  Dlifertnces  in  the  Syntax  structure 

The  sajor  difference  between  SQL  and  RQL  is  the 
syntactic  structure.  Using  the  database  in  Figure  1  from 
Date,  an  example  of  the  two  guery  languages  will  be  given. 

This  example  is  a  guery  to  list  the  names  of  all 
suppliers  who  do  not  provide  part  "P2”.  As  can  seen  from 
inspection  of  Figure  1  the  answer  would  be  one  supplier, 
ADAMS. 

SOLI  8ELECT  SNAWE 

FROM  S 

WHERE  *P2’  la  ALL 

(SELECT  P.NR 
FROM  SP 

The  guery  as  stated  in  RQL  Is: 

RQL I  RETRIEVE  (5.SNAME)  WHERE  0  a  ANT  (SP.P.NR  BY 

S.SNAME 

WHERE  SP.P.NR  a  "P2" 

ANC  S.S.NR  a  SP.S.NR)  GO 


TOR! 


71 


S.NR 

SHARE 

smug 

£121 

51 

SRITH 

20 

LONDON 

82 

JONES 

10 

PARIS 

S3 

BLAKE 

30 

PARIS 

54 

CLARK 

20 

LONDON 

S5 

ADARS 

30 

AlnERS 

P-WR 

1M 

CCLCR 

hum 

CITY 

PI 

NUT 

RED 

12 

LONDON 

P2 

8CLT 

GREEN 

17 

PARIS 

P3 

SCREW 

BLUE 

17 

PORE 

P4 

SCREW 

RED 

14 

LONDON 

P5 

CAR 

BLUE 

12 

PARIS 

P6 

CCG 

RED 

19 

LONDON 

SP 

5.  NR 

P-NR 

QTY 

51 

PI 

300 

81 

P2 

200 

51 

P3 

400 

81 

P4 

200 

51 

P5 

100 

51 

P6 

100 

82 

PI 

300 

82 

P2 

400 

53 

P2 

200 

84 

P2 

200 

54 

P4 

300 

54 

P5 

400 

Figure  1,  The  Supplier-Parts  Database 
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without  regard  to  implementation  the  above  queries 
are  resolved  as  follows: 

a,  in  the  SQL  example  the  sets  of  suppliers  and  the 
parts  they  supply  is  formed  by  the  nested  select.  Then 
the  outer  select  will  return  a  supplier's  name,  if  and 
only  if  the  set  of  parts  supplied  by  that  supplier  dees 
not  contain  "P2". 

b.  In  the  RGL  example  the  "by"  clause  establishes  the 
same  set  as  the  inner  seieet  of  the  SQL  query.  Then  the 
two  boolean  expressions  are  evaluated  with  the  "and" 
conjunction.  Zf  no  tuples  satisfy  tne  conditions  for  a 
given  supplier,  then  the  value  of  ant  (tuple)  is  0.  If 
ANY  Is  0,  the  qualification  evaluates  to  true,  and  the 
suppliers  name  is  returned.  S.s.nr  «  SP.S.NR  insures 
that  suppliers  In  the  5  relation  but  not  In  the  SP 
relation  are  not  Ignored  (i.e.,  that  a  supplier  who 
supplies  no  parts  will  be  Included  as  a  tuple  in  the 
answer  to  the  query). 

The  syntactic  structure  of  the  example  demonstrates 
the  major  differences  In  the  two  languages,  SQL  is  highly 
structured,  with  nested  selects.  On  the  other  hand,  RQL 
does  not  permit  nesting  of  retrieves  but  allows  nesting  of 
aggregate  functions  to  perform  the  same  operations. 
Although  It  would  be  purely  subjective  to  favor  one  method 
over  the  other,  It  appears  tnat  the  structured  approacn  of 
SQL  may  be  easier  to  learn  Initially.  However,  once  the 
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aggregate  functions  of  RQL  are  mastered,  the  lack  ct 
redundancy  nay  be  wore  attractive. 

3.  Other  Differences 

ROM  1100  does  not  lirpleirert  nulls,  but  does  supply 
default  values  (zeros  for  numeric  fields,  blanks  for 
character  fields).  Therefore,  tne  results  of  the  scalar 
aggregates  and  aggregate  functions  (AVG,  min,  max,  and  sum) 
are  not  always  predictable.  This  Implies  the  user  must  be 
extremely  knowledgeable  about  the  database  and  use  the 
aggregates  with  caution  (e.g.,  explicitly  exclude  zero 
values  from  aggregation).  In  SQL  queries  can  be  constructed 
with  "no  null"  as  a  qualifier  and  the  tuples  with  null 
values  In  the  attribute  being  aggregated  will  not  be 
Included  in  the  returned  value. 

SQL  uses  "ALL* ,  'HAVING',  'IN*,  and  others  to 
provide  a  more  set-theoretic  description  of  database 
■anlpulatlon.  RQL  provides  the  same  capability  In  the 
aggregate  functions  but  the  concept  of  set  manipulation  is 
not  explicit.  RQL  provides  a  *MCC'  function  and  some  string 
manipulation  functions  which  are  also  available  in  SQL.  The 
string  manipulation  functions  extend  the  power  of  rql 
particularly  when  working  with  database  relations  (l.e., 
non-user  defined  relations)  which  have  attributes  encoded  as 
binary  values. 

The  'HOC'  function  Is  not  correctly  Implemented  for 
negative  numbers  in  RQL  or  SQL.  It  returns  the  modulo  elass 
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of  the  argument  as  If  the  argument  were  a  positive  integer 
and  'attaches'  the  original  sign.  For  example,  -l  mod  8  = 
•(1  mod  8)  «  -1,  To  avoid  this  inconsistency  and  to 
eorreetly  Implement  the  mathematical  definition,  the 
following  nested  application  of  mod  Is  required  for  modulo 
8! 

mod  (mod  (ARG,  6)  ♦  8,  8), 

The  actual  function  Implemented  appears  to  be  a  remainder 
function  which  would  be  consistent  since  both  query 
languages  are  implemented  in  the  programming  language  C.  C 
has  a  remainder  function  but  not  a  mod  function. 


There  arc  thrta  major  areas  in  which  DBA  must  be 
knowledgeable  in  order  to  ensure  the  successful  management 
of  a  database  system.  These  areas  are  tne  user  services, 
performance  enhancements,  and  security  factors.  The 
specific  relational  database  management  system  or  backend 
machine  employed  will  dictate  the  amount  of  DBA  support 
required  in  each  area. 

The  user  services  include  the  stored  commands  provided 
by  DBA*  the  loading  of  data  into  the  system,  the  recovery  of 
the  database  as  a  result  of  system  malfunction,  and  a  help 
facility.  Although  these  are  not  comprehensive  and  the 
exact  amount  of  support  will  be  discretionary  on  the  part  of 
DBA,  they  do  form  the  nucleus  for  DBA's  planning  of  user 
support.  This  support  is  erltleal  to  the  acceptance  and  use 
of  the  relational  database  system  by  the  user  community. 

The  basic  tools  DBA  can  use  to  ennanee  performance  are 
the  implementation  of  the  language  features,  indices,  and 
data  placement.  The  performance  enhancement  which  can  be 
gained  from  the  query  language  is  only  aenievabie  if  DBA  has 
a  solid  understanding  of  the  lenguage  and  how  it  is 
implemented.  Certain  features  of  tne  language  will  be 
executed  faster  than  others  and  since  there  are  numerous 
ways  to  form  a  query  to  obtain  the  same  information, 
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knowledge  about  these  characteristics  can  achieve  more  rapid 
responses  from  the  database.  Therefore,  DBA  should  revie* 
user  commands  in  applications  programs  and  provide  guidance 


to  users 

for 

the  purpose 

of  exploiting  the 

more 

rapla 

features. 

Of 

eourse,  the 

specific  features 

will 

vary 

between  languages. 

Indices  provide  anotner  performance  tool  in  databases 
where  retrieval  and  joins  are  the  primary  operations.  Even 
if  these  operations  are  not  the  most  prevalent,  indices  may 
still  be  employed  to  enhance  performance,  if  the  database 
has  a  large  number  of  insertion  operations,  then  avoiding 
the  placement  of  indices  on  the  relations  which  are  changing 
frequently  will  not  result  in  serious  degradation 
attributable  to  the  Index  updating.  Additionally,  if 
relations  in  this  type  of  database  which  are  not  subject  to 
frequent  Insertions  but  are  used  in  numerous  retrieves  and 
joins  can  be  identified;  then  placement  of  indices  on  these 
relations  over  the  appropriate  attributes  *111  enhance  the 
overall  performance  of  the  database  system. 

The  ability  to  explicitly  place  aata  in  the  database 
should  provide  a  more  responsive  system.  In  order  to  take 
advantage  of  data  placement  CBA  must  know  what  relations 
exist  In  the  system  and  which  ores  are  joined  on  a  recurring 
basis. 

The  security  aspects  on  a  relational  database  system 
should  be  a  critical  issue  for  DBA.  since  a  single  database 
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will  be  used  by  various  users  in  the  organization,  there 
will  be  data  which  certain  groups  of  users  do  not  require  to 
perform  their  functions  and  mere  Importantly,  they  shoula 
not  be  allowed  to  access.  Although  there  is  more  to 
security  than  access  control,  this  appears  to  be  the  only 
mechanism  available  to  DBA  to  Implement  a  security  system  in 
the  database.  Consequently,  access  control  should  be 
employed  to  restrict  the  data  available  to  the  users  and 
simultaneously,  provide  a  relational  database  perspective  to 
each  user. 

In  RDt*  1100  there  is  a  trade-off  between  security, 
performance,  and  relational  perspective.  There  were  three 
methods  discussed  to  provide  a  single  external  view  of  the 
database  to  a  user  or  group  cf  user.  Caen  of  these  methods 
required  the  sacrifice  of  one  of  the  trade-off  features  and 
In  order  to  resolve  this  problem,  a  change  in  the 
implementation  of  ALL  Is  necessary. 

The  features  and  Issues  discussed  In  this  thesis  should 
provide  DBA  with  some  guidelines  and  topics  to  investlaate 
which  will  make  his  database  system  acceptable  and 
responsive  to  the  users.  Although  the  success  or  failure  of 
any  system  cannot  be  realistically  placed  on  a  single 
individual,  It  appears  DBA  win  be  more  responsible  than  any 
other  person  connected  with  the  system  if  it  does  not  meet 
the  users  perceived  needs. 
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APPENDIX  A 


EXAMPLES  OF  STORED  COMMANDS 

ACCESS-LIST 


DESTROY  ACCESS-LIST  GO 
DEFINE  ACCESS-LIST 

RETRIEVE  (RELATION, NAME,  RELATION. TYPE  , 

FIELDS  «  RELATION. ATTCNT,  RECORDS  *  RELATION .TUPS , 
USER  *  USERS. NAME) 

WHERE  RELATION, NAME  a  fO 

AND  PROTECT. RELIO  a  RELATION .PELID 
AND  PROTECT.USER  a  USERS. ID 

AND  MOD  (INTI  (SUBSTRING  (1,  1,  PROTECT. ATTMAP) ) ,  4)  a  1 
ENO  DEFINE  GO 

ASSOCIATE  ACCESS-LIST  WITH  "RETURNS  ACCESS  LIST  FOR  AN 

OBJECT”  GO 

ALL-INDICES 


DESTROY  ISTATUS  GO 

CREATE  ISTATUS  (STATUS  a  II,  DESC  a  C30)  GO 
APPEND  TO  ISTATUS  (STATUS  a  0. 

DESC  a  "N0NUNI0-N0NCLU5-N0  DEL  SILENT") 
APPEND  TO  ISTATUS  (STATUS  a  1, 
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CESC  *  "UNIG-NCNCLUS*NO  DEL  SILENT1*) 

APPEND  TO  ISTATUS  (STATUS  a  2, 

CESC  a  "NQNUNIQ-CLUS-NO  DEL  SILENT" ) 

APPEND  TO  ISTATUS  (STATUS  *  3, 

CESC  a  "UNIO-CLUS-NO  CEL  SILENT") 

APPEND  TO  ISTATUS  (STATUS  a  4, 

CESC  s  "NCNUNIO-NONCLUS-DEL  SILENT") 

APPEND  TO  ISTATUS  (STATUS  a  5 , 

CESC  a  "UNIQ-NCNCLLS-DEL  SILENT") 

APPEND  TO  ISTATUS  (STATUS  «  6, 

CESC  a  "NONUNIQ-CLUS-DEL  SILENT") 

APPEND  TO  ISTATUS  (STATUS  a  7, 

CESC  a  "UNIG-ClUS-CEl  SILENT") 

PERMIT  REAO  OF  ISTATUS  TO  ALL 
DENY  WRITE  OF  ISTATUS  TO  ALL  GO 
DESTROY  ALL.INCICES  GO 
DEFINE  ALL.INCICES 

RETRIEVE  (REL  a  REL.NAME  ( INDICES. RELID) ,  INDICES, INDID, 

INDICES,  ATTCNT,  ISTATUS. CESC) 
ORDER  BY  REL.NAME  ( INDICES .RELID ) 

toHERE  ISTATUS, STATUS  3  MCD  (MOD  (INDICES, STAY,  8)  ♦  8 ,  8) 
AND  RELATICN, RELID  a  INDICES .RELID 
AND  RELATICN. TYPE  a  "U" 

END  DEFINE  GO 

ASSOCIATE  ALL.INCICES  WITH  "LIST  ALL  INDICES  CN  USER 

RELATIONS"  GO 
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ATT.IN.INDX1 


DESTROY  ATT.IN.INDX1  GO 
DEFINE  ATT.XN.XNDX1 
RETRIEVE  (ZNCXCE5.INDID, 

ATT1  s  FIELD.NAME  (INDICES .RELIC ,  INTI  (SUBSTRING 

(4,  1,  INDICES. KEYS))), 

ATT2  «  FIELD.NAME  ( INDICES . RELID ,  INTI  (SUBSTRING 

(14,  1,  INDICES. KEYS))), 

ATT3  s  FIELD.NAME  (INDICES , RELID ,  INTI  (SUBSTRING 

(24,  1,  INDICES. KEYS))), 

ATT4  a  FIELD.NAME  (INDICES. RELID,  INTI  (SUBSTRING 

(34,  1,  INDICES. KEYS))), 

ATTS  *  FIELD.NAME  ( INDICES . RElID ,  INTI  (SUBSTRING 

(44,  1,  INDICES. KEYS))), 

ATT6  «  FIELD.NAME  (INDICES.RELID,  INTI  (SUBSTRING 

(54,  1,  INDICES. KEYS))), 

ATT7  s  FIELD.NAME  (INDICES.RELID,  INTI  (SUBSTRING 

(64,  1,  INDICES. KEYS)  ))  , 

ATT8  s  FIELD.NAME  (INDICES.RELID,  INTI  (SUBSTRING 

(74,  1,  INDICES .KEYS)))) 

NHERE  INDICES. INDID  ■  SO 

AND  INDICES.RELID  3  PEL. ID  (81) 

END  DEFINE  GO 

ASSOCIATE  ATT.IN.INCX 1  NITN  "LISTS  NAMES  OF  ATTRIBUTES  IN 

INDEX"  GC 
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ATT.IN-INCX2 


DESTROY  ATT.IN.INCX2  GO 
DEFINE  ATT.IN.IN0X2 
RETRIEVE  (INDICES. INDID, 

ATT9  a  FIELD. NAME  £  INDICES , RELID ,  INTI  (SUBSTRING 

(84.  1.  INDICES. KEYS)))  . 

ATTIO  «  FIELD. NAME  £  INDICES , RELID .  INTI  (SUBSTRING 

(94.  1.  INDICES. KEYS))) , 

ATT11  a  FIELD. NAME  ( INDICES . RELID ,  INTI  (SUBSTRING 

(104.  1.  INDICES. KEYS))). 

ATT12  a  FIELD.NAME  ( INDICES. RELID ,  INTI  (SUBSTRING 

(114.  1.  INDICES. KEYS))). 

ATT13  a  FIELD.NAME  (INDICES. RELID,  INTI  (SUBSTRING 

(124.  1.  INDICES. KEYS))). 

ATT14  a  FIELD.NAME  ( INDICE5 .RLL1D .  INTI  (SUBSTRING 

(134.  1.  INDICES. KEYS)))  , 

ATT1S  a  FIELD.NAME  (INDICES. RELID.  INTI  (SUBSTRING 

(144.  1.  INDICES. KEYS))). 

ATT16  a  FIELD.NAME  ( INDICES . RELID ,  INTI  (SUBSTRING 

(154.  1.  INDICES. KEYS)))) 

MHERE  INDICES. INDID  a  SO 

AND  INDICES. RELID  ■  REL.ID  (Si) 

END  DEFINE  GO 

ASSOCIATE  ATT.IN.INDX2  NITH  "LISTS  NAMES  CF  ATTRIBUTES  IN 


INDEX"  GO 


•nwrTTOTOrriTC' '.w !.%  J*  r*  \\  w:*  ■*  7T7*r»n 


ITT  '  i  ■'! ■  J«y  ij'f 


CEPgNCS 


DESTROY  DEPENDS  CO 


DESTROY  OTYPE  GO 

CREATE  OTYPE  (TYPE  *  UC1,  DESC  *  UC15)  GO 


APPEND 

TO 

OTYPE 

(TYPE 

X 

"U", 

DESC 

X 

"USER  TABLE 

") 

GO 

APPEND 

TO 

OTYPE 

(TYPE 

X 

"S", 

DESC 

X 

"SYSTEM  TABLE 

") 

GO 

APPEND 

TO 

OTYPE 

(TYPE 

X 

"T", 

DESC 

X 

"TRANSACTION  LOG 

") 

GO 

APPEND 

TO 

OTYPE 

(TYPE 

X 

"F", 

DESC 

X 

"FILE 

GO 

APPEND 

TO 

OTYPE 

(TYPE 

X 

"V", 

DESC 

X 

"USER  VIEW 

") 

GO 

APPEND 

TO 

OTYPE 

(TYPE 

X 

"C", 

DESC 

X 

"STORED  COMMAND 

») 

GO 

DENY  WRITE  OF  OTYPE  GO 
DENY  READ  OF  OTYPE  GO 
OEriNE  DEPENOS 

RETRIEVE  (OBJECT  *  RELATION , NAME ,  WHICH.I5.A  * 

STRING  (1S#  CIYPE.CESC),  DEPENDS. ON  x  $1) 
WHERE  CROSSREF, RELIC  *  REL.IC  ($1) 

AND  CRCSSREF .DRELID  *  RELATION, RELID 
AND  OTYPE, TYPE  »  RELATION  .TYPE 
END  DEFINE  GO 

ASSOCIATE  DEPENDS  WITH  "LISTS  DEPENDENCIES  OF  THE  NAMED 

OBJECT"  GO 

FIELDS 

DESTROY  FIELDS  GO 
DESTROY  FIELD.EQUIV  GO 
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CREATE  FIELD. EQUXV  (NAME  a  UC4 ,  NUM  a  II)  CO 
APPEND  TO  FIELD.EQUIV  (NAME  a  "FLT  ",  NUM  a  35)  GO 

APPEND  TO  FIELD.EQUIV  (NAME  a  "BIN  ",  NUM  a  45)  GC 

APPEND  TO  FIELD.EQUIV  (NAME  »  "CHAR",  NUM  a  47)  GC 

APPEND  TO  FIELD.EQUIV  (NAME  a  "InT  ",  NUM  a  48)  GC 

APPEND  TO  FIELD.EQUIV  (NAME  a  »IM  ",  NUM  a  52)  GO 

APPEND  TO  FIELD.EQUIV  (NAME  a  "INI  ",  NUM  a  56)  GC 

DEFINE  FIELDS 

RETRIEVE  (TA8LC  a  RELATION. NAME,  FIELD  a  ATTRIBUTE. NAME, 

TYPE  «  FIELD.EQUIV. NAME,  LEN  a  ATTRIBUTE. LEN) 
WHERE  ATTRIBUTE. RELID  a  RELATION .RfcLID 
AND  RELATION, NAME  «  STABLE. NAME 
AND  FIELD.EQUIV .NUM  a  ATTRIBUTE .TYPE 
END  DEFINE  GO 

ASSOCIATE  FIELDS  WITH  "RETURNS  ALL  FIELDS  IN  THE  NAMED 

RELATION"  GO 


HELP.REL 


mi 


OBJECT  LINE. NO  DESCRIPTION 

ATT.IN.INDX1  1  THIS  IS  A  STORED  COMMAND  WHICH  HAS 

2  TWC  PARAMETERS.  THE  FIRST  PARA- 

3  METER  IS  THE  INDEX  ID  NO.  AND  THE 

4  SECOND  IS  THE  RELATION  NAME, 
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5  THESE  PARAMETERS  MUST  BE  SEPAR- 

6  ATED  BY  COMMAS.  THIS  COMMAND 

7  PRCVICES  THE  ATTRIBUTE  NAMES  OF 

8  EACH  ATTRIBUTE  IN  THE  INDEX  FOR 

9  THE  GIVEN  RELATION  OR  VIEW.  TO 

10  EXECUTE  THIS  COMMAND  JUST  TYPE 

11  IN  "HELP*  FOLLOWED  BY  THE  OBJECT 

12  NAME  AND  "GO". 

DESTROY  HELP  GO 
DEFINE  HELP 

RETRIEVE  (HELP.REL. DESCRIPTION) 

ORDER  BY  HELP.REL.LINE.NQ  *  A 
WHERE  HELP.REL. OBJECT  »  JOEJECTNAME 

AND  PROTECT. RELID  «  REL.ID  (HELP.REL. OBJECT) 

AND  PROTECT .USER  »  USERID  () 

AND  (MOD  (INTI  (SUBSTRING  (1.  1.  PROTECT, ATTMAP) ) , 

4)  *  1) 

END  DEFINE  GO 

PERMIT  EXECUTE  OF  HELP  TO  ALL 

ASSOCIATE  HELP  WITH  "PROVIDES  INFORMATION  ABOUT  THE  OBJECT 

PASSED  AS  A  PARAMETER"  GO 

INDEX. LIST 


DESTROY  INOEX.LIST  GO 
DEFINE  INDEX.LIST 
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4 


RETRIEVE  (RELATION. NAME,  INDICES  .  INDIO .  INDICES. ATTCNT , 

ISTATUS, DESC ) 

ORDER  BY  INDICES.  INDIC 
WHERE  INDICES. RELID  *  RELATION . RELIC 
AND  RELATIGN.NAME  *  SO 

AND  ISTATUS. STATUS  ■  MOD  (NOD  (INDICES. STAT,  8) 

♦  8,  8) 

END  DEriNE  GO 

ASSOCIATE  INOEX.LIST  WITH  "LIST  INDICES  ON  NAMED 

RELATION/VIEW"  GO 

PROTECTION 


DESTROY  PTYPE  GO 
DESTROY  ATYPE  GO 

CREATE  PTYPE  (ACCESS  a  II,  CESC  a  UC15)  GO 

APPENO  TO  PTYPE  (ACCESS  a  1,  CESC  a  "HEAD  ") 

APPEND  TO  PTYPE  (ACCESS  *  2,  CESC  a  ” mRITE  ") 

APPEND  TO  PTYPE  (ACCESS  a  3,  CESC  a  "ALL  ") 

APPEND  TO  PTYPE  (ACCESS  a  -32,  CESC  a  "EXECUTE  ”  ) 

APPEND  TO  PTYPE  (ACCESS  a  -53,  CESC  a  "CREATE  DATABASE”) 

APPEND  TO  PTYPE  (ACCESS  a  -56,  CESC  a  "CREATE  ") 

APPEND  TO  PTYPE  (ACCESS  a  -56,  CESC  a  "CREATE  INDEX  ”)  GO 

PERMIT  READ  OF  PTYPE  GO 
DENY  WRITE  OF  PTYPE  GO 

CREATE  ATYPE  (ACCESS  a  II,  CESC  *  UC8)  GO 
APPENO  TO  ATYPE  (ACCESS  a  I ,  CESC  >  "PERMIT  ") 
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APPEND  TO  ATYPE  (ACCESS  a  2,  DESC  *  "DENY  *) 

APPEND  TQ  ATYPE  (ACCESS  a  3,  DESC  *  "BOTH  •)  GO 

PERMIT  READ  OF  ATYPE  GO 

OENY  WRITE  OF  ATYPE  GO 

DESTROY  PROTECTION  GO 

OEFINC  PROTECTION 

RETRIEVE  (ACCESS  •  CONCAT  (ATYPE. DESC,  PTYPE.DESC), 

OBJECT  a  RELATION. NAME,  USER  a  USERS. NAME) 
WHERE  ATYPE. ACCESS  a  MCO  (INTI  (SUBSTRING  (1,  1, 

PROTECT, ATTMAP) ) ,  4) 

AND  PTYPE. ACCESS  ■  PROTECT . ACCESS 
AND  RELATION .RELXD  a  PROTECT. RELID 
ANO  RELATION, NAME  a  SO 
AND  PRCTECT.USER  a  USERS. ID 
END  DEFINE  GO 

ASSOCIATE  PROTECTION  WITH  "CI5PLAY  PROTECTION  DATA  ABOUT 

IHE  NAMED  RELATION"  GO 

lAflfcEfi 

DESTROY  TABLES  GO 
DEFINE  TABLES  GO 

RETRIEVE  (RELATION. NAME,  RELATION. TYPE ,  FIELDS  a 

RELATION. ATTCNT,  RECORDS  a  RELATION .TUPS) 
ORDER  BY  RELATION. NAME  j  A 
WHERE  RELATICN.TYPE  a  |0 
END  DEFINE  GO 
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ASSOCIATE  TABLES  WITH  "RETURNS  LIST  OF  RELATIONS,  VIEWS  OR 

STORED  COMMANDS"  GC 


»HATIS 


DESTROY  WHATIS  GO 
DEFINE  WHATIS 

RETRIEVE  (RELATION  a  REL.NANE  (DESCRIPTIONS. RELID) , 

EXPLANATION  a  DESCRIPTIONS. TEXT) 

WHERE  DESCRIPTIONS, RELID  s  REL.ID  ($0) 

END  DEFINE  GO 

ASSOCIATE  WHATIS  WITH  "EXPLAINS  WHAl  A  STORED 

CCNNAND/RELATION  DOES/IS”  GO 

WHOCREATES 

DESTROY  WHOCREATES  GO 

DEFINE  WHOCREATES 

RETRIEVE  (USERS. NAME.  PTYPE.OESC) 

WHERE  PROTECT. USER  a  USERS. ID 

AND  (PROTECT. ACCESS  a  .53  OR  PROTECT. ACCESS  a  -56  OR 

PROTECT .ACCESS  *  -58) 
AND  PROTECT. ACCESS  a  PTYPE. ACCESS 
AND  MOD  (INTI  (SUBSTRING  (1,  I,  PROTECT, ATTMAP) ) , 

4)  a  l 

END  DEFINE  GO 

ASSOCIATE  WHOCREATES  WITH  "LIST  USERS  WHO  HAVE  CREATE 


PERMISSION"  GC 
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